1
votes

I think that I'm in a NuGet Dll hell.

My first problem have ocurred with:

Could not load file or assembly 'System.Net.Http.Primitives, Version=1.5.0.0, Culture=neutral, PublicKeyToken=b03f5f711d50a3a' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference.

But I could solve it putting the right dependentAssembly in web.config/app.config.

Now, I have new error that I don't any idea about how to solve it

ThreadAbortExceptionSubproceso anulado. - Data: System.Collections.ListDictionaryInternal - Stack Trace: en Google.Apis.Requests.ClientServiceRequest1.Execute() en c:\code\google.com\google-api-dotnet-client\default\Tools\Google.Apis.Release\bin\Debug\test\default\Src\GoogleApis\Apis\Requests\ClientServiceRequest.cs:línea 100 en AppLayer.Control.Engines.Database.Bigquery.InsertAll(BigqueryService s, String datasetId, String tableId, List1 data) en d:\Programació\Nostrum\BACKEND\AppLayer\Control\Engines\Database\Bigquery.cs:línea 175 - Source : Google.Apis - InnerException: Subproceso anulado. Google.Apis 21/10/2014 17:04:10 ThreadAbortExceptionSubproceso anulado.System.Collections.ListDictionaryInternal System.Collections.Generic.List`1[Google.Apis.Bigquery.v2.Data.TableDataInsertAllRequest+RowsData]

I'm using Visual Studio 2012 Update 4, and this is my code

public bool InsertAll(BigqueryService s, String datasetId, String tableId, List<TableDataInsertAllRequest.RowsData> data)
    {
        try
        {
            TabledataResource t = s.Tabledata;
            TableDataInsertAllRequest req = new TableDataInsertAllRequest()
            {
                Kind = "bigquery#tableDataInsertAllRequest",
                Rows = data 
            };
            //My code crashes in the next line 
            TableDataInsertAllResponse response = t.InsertAll(req, projectId, datasetId, tableId).Execute();
            if (response.InsertErrors != null)
            {
                return true;

            }
        }
        catch (ThreadAbortException e)
        {
            throw e;

        }
        catch (Exception e)
        {
            throw e;
        }
            return false;
    }

Anybody have any idea about how to fix this? I'm very frustrated...

If I remove the catch blocks, I'm getting this in Output window

'vstest.executionengine.x86.exe' (Managed (v4.0.30319)): Loaded 'C:\Windows\Microsoft.Net\assembly\GAC_MSIL\mscorlib.resources\v4.0_4.0.0.0_es_b77a5c561934e089\mscorlib.resources.dll' 'vstest.executionengine.x86.exe' (Managed (v4.0.30319)): Loaded 'C:\Windows\Microsoft.Net\assembly\GAC_MSIL\System.Threading.Tasks\v4.0_4.0.0.0__b03f5f7f11d50a3a\System.Threading.Tasks.dll' 'vstest.executionengine.x86.exe' (Managed (v4.0.30319)): Loaded 'D:\Programació\Nostrum\BACKEND\TestSubmitService\bin\Debug\Microsoft.Threading.Tasks.dll' A first chance exception of type 'System.Threading.ThreadAbortException' occurred in mscorlib.dll A first chance exception of type 'System.Threading.ThreadAbortException' occurred in Google.Apis.dll A first chance exception of type 'System.Threading.ThreadAbortException' occurred in Google.Apis.dll 'vstest.executionengine.x86.exe' (Managed (v4.0.30319)): Loaded 'C:\PROGRAM FILES (X86)\MICROSOFT VISUAL STUDIO 11.0\COMMON7\IDE\COMMONEXTENSIONS\MICROSOFT\TESTWINDOW\es\Microsoft.VisualStudio.TestPlatform.TestExecutor.Core.resources.dll' 'vstest.executionengine.x86.exe' (Managed (v4.0.30319)): Loaded 'C:\Windows\Microsoft.Net\assembly\GAC_MSIL\System.Transactions.resources\v4.0_4.0.0.0_es_b77a5c561934e089\System.Transactions.resources.dll' System.Transactions Critical: 0 : http://msdn.microsoft.com/TraceCodes/System/ActivityTracing/2004/07/Reliability/Exception/UnhandledExcepción no controladavstest.executionengine.x86.exeSystem.AppDomainUnloadedException, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089Intento de obtener acceso a un AppDomain descargado. System.AppDomainUnloadedException: Intento de obtener acceso a un AppDomain descargado. An exception of type 'System.Threading.ThreadAbortException' occurred in Google.Apis.dll but was not handled in user code Step into: Stepping over non-user code 'System.Threading.ExecutionContext.RunInternal' The thread '' (0x77c) has exited with code 0 (0x0). The thread '' (0xd44) has exited with code 0 (0x0). 'vstest.executionengine.x86.exe' (Managed (v4.0.30319)): Loaded 'C:\Windows\Microsoft.Net\assembly\GAC_MSIL\System.Xaml\v4.0_4.0.0.0__b77a5c561934e089\System.Xaml.dll', Skipped loading symbols. Module is optimized and the debugger option 'Just My Code' is enabled. 'vstest.executionengine.x86.exe' (Managed (v4.0.30319)): Loaded 'C:\Windows\Microsoft.Net\assembly\GAC_MSIL\System.ServiceModel.resources\v4.0_4.0.0.0_es_b77a5c561934e089\System.ServiceModel.resources.dll' 'vstest.executionengine.x86.exe' (Managed (v4.0.30319)): Loaded 'C:\Windows\Microsoft.Net\assembly\GAC_MSIL\System.resources\v4.0_4.0.0.0_es_b77a5c561934e089\System.resources.dll' The program '[4552] vstest.executionengine.x86.exe: Program Trace' has exited with code 0 (0x0). The program '[4552] vstest.executionengine.x86.exe: Managed (v4.0.30319)' has exited with code 0 (0x0).

1
Get rid of your catch blocks; they destroy stack traces.SLaks
I've updated my post with error trace that run program without catch blockRCalaf
A ThreadAbortException means the code tried to abort the running thread. Do you have any code that aborts threads? It may be that the Google API itself aborts the thread in case of timeouts, but it's unlikely. Are you running the code inside a unit test?Panagiotis Kanavos
Yes @Panagiotis Kanavos, I run code inside a unit testRCalaf

1 Answers

2
votes

Your code is running inside a unit test, as evidenced by vstest.executionengine.x86.exe. When the test finishes, it tries to abort any running threads, thus the ThreadAbortException. It seems that the Google API code is still running on a background thread which gets killed when the test ends.

Fix your test code so that the test doesn't finish before the Google API operation completes. Without looking at the test code, or the code that spawns the background thread, one can only guess how to fix it.

The best option is to use Tasks instead of raw threads and expose the task, so that your test can await on the Task. Another option is to have the thread signal an event (eg an AutoResetEvent) on which the test will wait.