Assemblies Failing to load in shadow copied AppDomain - appdomain

I write the xunit.net test runner for ReSharper, and I've got an issue in the 8.0 release - I'm seeing assemblies failing to load in a shadow copied AppDomain. The same code and test project work fine in the 7.1 release. I don't understand why, though.
When running tests, ReSharper spawns an executable that loads my plugin. I use xunit.net's API to create an AppDomain that has shadow copy enabled. The test project assembly is copied into the shadow copy cache, and starts to load. It copies a dependency into the cache, and loads it - an older version of FakeItEasy, which uses Assembly.LoadFile to load all of the assemblies in the current directory, which is the bin\Debug folder of the test project. So, FakeItEasy loads these assemblies into the Neither load context. Since it's using LoadFile, it bypasses the shadow copy cache, and the files are loaded direct from the bin\Debug folder.
After this, the dependencies of the test project fail to load, resulting in a FileNotFoundException. Fusion binding logs show that it tries to load them, but they don't get copied in the shadow copy cache, and they fail to load. I can't see why. Here's the binding failure:
LOG: This bind starts in default load context.
LOG: No application configuration file found.
LOG: Using host configuration file:
LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework64\v4.0.30319\config\machine.config.
LOG: Policy not being applied to reference at this time (private, custom, partial, or location-based assembly bind).
LOG: Attempting download of new URL file:///C:/temp/todonancy/TodoNancyTests/bin/Debug/Nancy.Testing.DLL.
LOG: Assembly download was successful. Attempting setup of file: C:\temp\todonancy\TodoNancyTests\bin\Debug\Nancy.Testing.dll
LOG: Entering download cache setup phase.
LOG: Assembly Name is: Nancy.Testing, Version=0.17.1.0, Culture=neutral, PublicKeyToken=null
ERR: Setup failed with hr = 0x80070003.
ERR: Failed to complete setup of assembly (hr = 0x80070003). Probing terminated.
If I disable shadow copy cache, or use a newer version of FakeItEasy that doesn't use LoadFile, it all works. However, I can't blame the older vesion of FakeItEasy - I have users seeing the same errors with other projects and assemblies, all solved by disabling shadow copy cache.
Also, this scenario does work with ReSharper 7.1 - same plugin code and same test project. The only difference is the host application, but I can't see it doing anything different - there are no other assembly resolve event handlers subscribed, for example. The only real difference is that the 7.1 host uses remoting to talk to the Visual Studio application, and the 8.0 uses simple TCP sockets.
Does anyone have any idea why this is failing in the 8.0 version, and yet running with 7.1?
EDIT (07/08/2013):
I've managed to make it fail with a simple test:
[Fact]
public void Thing()
{
Assert.NotNull(Nancy.Bootstrapper.AppDomainAssemblyTypeScanner.Assemblies);
}
Using a copy of the Nancy class added straight into the project (with the referenced ScanMode and AssemblyExtensions classes). The only other content in the project is a reference to xunit.dll and xunit.extensions.dll.
It doesn't fail every time, it's frustratingly intermittent, but I can get it to throw a FileNotFoundException in this call to Assembly.ReflectionOnlyLoadFrom while trying to load the test assembly from the bin\Debug folder.
Here's the fusion log from the exception:
Assembly manager loaded from: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\clr.dll
Running under executable C:\Program Files (x86)\JetBrains\ReSharper\v8.0\Bin\JetBrains.ReSharper.TaskRunner.CLR4.MSIL.exe
--- A detailed error log follows.
=== Pre-bind state information ===
LOG: Where-ref bind. Location = C:\Users\Matt\Code\scratch\WeirdXunitFailures\WeirdXunitFailures\bin\Debug\WeirdXunitFailures.dll
LOG: Appbase = file:///C:/Users/Matt/Code/scratch/WeirdXunitFailures/WeirdXunitFailures/bin/Debug
LOG: Initial PrivatePath = NULL
Calling assembly : (Unknown).
===
LOG: This is an inspection only bind.
LOG: No application configuration file found.
LOG: Using host configuration file:
LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework64\v4.0.30319\config\machine.config.
LOG: Attempting download of new URL file:///C:/Users/Matt/Code/scratch/WeirdXunitFailures/WeirdXunitFailures/bin/Debug/WeirdXunitFailures.dll.
ERR: Failed to complete setup of assembly (hr = 0x80070003). Probing terminated.
Unfortunately, this tells me nothing - the file:// url is valid, and the shadow copy cache contains xunit.dll and WeirdXunitFailures.DLL (the test project). Also, the Modules window in the debugger is showing me that WeitdXunitFailures.dll is already loaded, from the shadow copy cache location.
And again, the really weird thing is that the 7.1 runner works just fine.
EDIT:
In fact, I can get it to fail simply by calling:
[Fact]
public void Thing()
{
Assembly.ReflectionOnlyLoadFrom(#"C:\Users\Matt\Code\scratch\WeirdXunitFailures\WeirdXunitFailures\bin\Debug\xunit.dll");
Assembly.ReflectionOnlyLoadFrom(#"C:\Users\Matt\Code\scratch\WeirdXunitFailures\WeirdXunitFailures\bin\Debug\xunit.extensions.dll");
Assembly.ReflectionOnlyLoadFrom(#"C:\Users\Matt\Code\scratch\WeirdXunitFailures\WeirdXunitFailures\bin\Debug\WeirdXunitFailures.dll");
}
These are the project dll and the two xunit dlls. It's still very intermittent, but seems to be most easily reproduced after a complete rebuild, although it does still occur after several successful runs (so it's not the rebuild that's at fault)

Phew. The problem was (naturally) a subtle change in behaviour in ReSharper 8.
The test runner process API has a method to tell the main ReSharper process (i.e. devenv.exe) the location of the temp folder used for the test run - the shadow copy cache. This is because the test runner process usually can't delete the cache folder because it's still in use. ReSharper will then make several attempts to delete the folder for you, allowing time for the process to die gracefully.
ReSharper 7.1 would delete this folder at the end of a test run, or if the run was aborted.
ReSharper 8 deletes the folder as soon as you call you the method. The nunit test runner tells ReSharper about it at the end of the test run. I was telling it about it at the start. And so ReSharper would happily come along, while my tests were running, and delete whatever it could from the shadow copy cache, making it look like the shadow copy cache was properly broken.
I think I'll be filing a bug :)

Related

WCF unable to load DLLImported dll

I have a WCF service which references LevelDB-sharp (https://github.com/meebey/leveldb-sharp) which in turn references (DllImport) leveldb.dll.
Everything runs perfectly on my development machine, but as soon as I deploy it to live, I get the error message
The server encountered an error processing the request. The exception
message is 'Unable to load DLL 'leveldb.dll': The specified module
could not be found. (Exception from HRESULT: 0x8007007E)
I've tried putting the dll in the web service directory, the bin subdirectory, system32 and also system32\inertsrv and keep getting the same error.
I've also tried hard coding a path into the DllImport calls.
What am I missing?
DllImport calls does not follow the normal .net probing path ,it will look through windows PAth variable paths.
Since you have already tried to put the dll to inetsrv and system32,I guess your IIS webapplication pool may be running on 32bit mode.Are you running your application pool in 32 bit mode ?
If so, Please try and put the leveldb.dll in your syswow64 folder or
C:\Windows\SysWOW64\inetsrv folder

nHibernate not creating Oracle driver in MSTests run on command line

I've been working on this particular issue for a couple weeks now, and I'm exceedingly frustrated. As such, I'll give all the information I can and hope for the best.
My team is working on building a new application. Here's the alphabet soup:
.Net 4.5.1
nHibernate 4.0.0.4000 with FluentNHibernate 2.0.3.0
Oracle 11g (Oracle.DataAccess 2.112.1.0, which has Copy Local set to true)
Visual Studio 2013 is the IDE
Windows 7 Professional
I am compiling the application as a 32-bit app, and I have confirmed that I have the 32bit version of Oracle installed.
We've written some tests for the NHibernate mappings, which we run through MSTest. When we run these through Visual Studio's test explorer, they all run properly and pass. The application itself also properly compiles and deploys as it should. We've verified the tests are running properly by checking the database between steps, so we're fairly sure that the tests themselves aren't the problem.
When we run MSTest through the command line though, we receive the following error:
Initialization method MyTests.Setup threw exception. NHibernate.HibernateException: NHibernate.HibernateException: Could not create the driver from NHibernate.Driver.OracleDataClientDriver. ---> System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.ArgumentException: Unable to find the requested .Net Framework Data Provider. It may not be installed..
I've tried reinstalling Oracle to no effect. I've tried checking the machine.config file for errors (as suggested in other posts here on SO) and found none.
Our Fluent configuration is as follows:
OracleDataClientConfiguration.Oracle10
.ConnectionString(connectionString)
.Driver("NHibernate.Driver.OracleDataClientDriver")
.ShowSql()
.FormatSql();
The code I'm running on the command line is the following:
(cd to the directory where the test .dll is)
>"C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\MSTest.exe" /testcontainer:MyTests.dll /test:UnitTests
I feel like I'm missing something here. Any ideas?
Update: Solution Found
So here's a weird one. I followed Fran's solution below and installed the Oracle.ManagedDataAccess package and changed the NHibernate driver in our configuration above to NHibernate.Driver.OracleManagedDataClientDriver. As per our quick comment-discussion, this lead to a new error:
Initialization method MyTests.Setup threw exception. NHibernate.HibernateException: NHibernate.HibernateException: Could not create the driver from NHibernate.Driver.OracleManagedDataClientDriver. ---> System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.Configuration.ConfigurationErrorsException: Failed to find or load the registered .Net Framework Data Provider
Fran then lead me to another SO question which encouraged me to check the Oracle configuration piece by piece. What better way to do this than create a test?
var x = new OracleConnection(connectionString);
x.Open();
Assert.IsTrue(x.State == System.Data.ConnectionState.Open);
x.Close();
Assert.IsFalse(x.State == System.Data.ConnectionState.Open);
In my quick attempt to run this test, I ran the whole collection of UnitTests with the script I'd mentioned above. Low and behold, every test passes!
Doing my due diligence, try the following
I comment out that test, clean, rebuild, and run the script again. Failures.
I return to the old Oracle driver and add that new test in. Clean, Rebuild, Run. Failures.
Add back the new Oracle driver, make sure the new test is still in. Run tests OTHER than the new test. Passes.
For some reason, the combination of the new driver and explicitly referencing it in a test seems to have resolved the issue. I'm open for any theories as to why, but I bet that qualifies as a new question.
I would stop using the bit specific version of the oracle drivers and move to the managed driver (https://www.nuget.org/packages/Oracle.ManagedDataAccess/). It is bit agnostic, and doesn't require you to install the Oracle client at all.
I actually found the solution to the problem, and it all has to do with how the Oracle.DataAccess.dll file gets loaded at runtime (Disclosure: I work with wadeb on the same project).
It seems that Oracle.DataAccess.dll was being searched for in every location on the server except the build output folder in the Jenkins workspace, and as such was pulling the DLL file from the GAC.
One of the file paths used to find the DLL file is the folder in which the "current executable" is located. In our case, the "current executable" was mstest.exe. Copying the Oracle.DataAccess.dll file to C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE did the trick.
Did it work. Yes.
Was it a hack? Absolutely -- but now it works without having to upgrade to the managed Oracle drivers.
Our servers weren't using an Oracle client that worked with the managed driver, and it wasn't acceptable to have a broken continuous integration build until servers get upgraded.
I have got just the same error and I switched my tests to x64 and it works like a charm now:

MSBuild SonarQube Runner v1.0 returns with code 1 after "Generating the FxCop ruleset"

I'm trying out SonarQube using the new MSBuild SonarQube Runner v1.0. If I install a fresh SonarQube server locally, the following command works fine, and I can build my solution directly afterward, call the 'end' command, and have the results published in SonarQube:
MSBuild.SonarQube.Runner.exe begin /key:TestKey /name:TestName /version:1.0.0.0
However, if I run this against an existing SonarQube server that exists on the internal network, it always returns with exit code 1:
15:32:40 Creating config and output folders...
15:32:40 Creating directory: c:\Test\MSBuild.SonarQube.Runner-1.0.itsonar\.sonarqube\conf
15:32:40 Creating directory: c:\Test\MSBuild.SonarQube.Runner-1.0.itsonar\.sonarqube\out
15:32:41 Generating the FxCop ruleset: c:\Test\MSBuild.SonarQube.Runner-1.0.itsonar\.sonarqube\conf\SonarQubeFxCop-cs.ruleset
Process returned exit code 1
It seems to download a lot of the dependencies into /.sonarqube, so communication with the server isn't an issue
Things I've tried:
checked the access.log, server.log and event logs
upgraded the existing server to v5.1.2 (clean install using the guide)
upgraded the sonar-csharp-plugin to v4.1
right-clicked all .jar files on the server and ensured they are unblocked
tried the runner directly on the server
(ongoing) tried debugging the source code (happening somewhere in the pre-process step: success comes back as true, but the error code is 1)
disabled UAC on the server an rebooted
re-installed JRE on both server and client, ensure JAVA_HOME in both PATH and registry are set correctly
Any help or pointers greatly accepted. I've been stuck on this for 2 days and can't think of anything else to try except continue trawling through source code. Thank you.
This is a tricky one! Looking at the code, I see only one path that can yield this output:
It fails while generating the FxCop ruleset for C#, as the VB.NET FxCop ruleset message is not logged - see TeamBuildPreProcessor.cs#L149 and TeamBuildPreProcessor.cs#L185
The GenerateFxCopRuleset() call for C# threw a WebException, leading to the call of Utilities.HandleHostUrlWebException() - which has to return true for the exception to be silently swallowed - see Utilities.cs#L153
The only path returning true without logging any message is if a HttpStatusCode.NotFound was received - see Utilities.cs#L158
The control flow goes back to FetchArgumentsAndRulesets(), which returns false, then goes back to Execute() which returns false as well - see TeamBuildPreProcessor.cs#L106
The MSBuild SonarQube Runner "begin" phase (called "preprocessor" in the code) fails - see Program.cs#L42
So, at some point, some SonarQube web service required for the C# FxCop ruleset generation is return a HTTP 404 error.
Could you monitor your network traffic and listen for the failing HTTP call? [I will keep on updating this answer afterwards]
EDIT: Indeed the error is caused by the quality profile name containing special characters. Such characters are currently badly URL-escaped, which leads to a 404.
I've created the following ticket to fix this issue in the upcoming release: http://jira.sonarsource.com/browse/SONARMSBRU-125

Application crashes on startup - missing Microsoft.VisualBasic.PowerPacks

I wrote a simple VB.NET application which works fine on the development machine.
However on another machine, even though the .NET Framework is installed, it crashes on startup with System.InvalidOperationException.
There seems to be a problem with it finding the Visual Basic assemblies.
Here is one of the fails (I replaced sensitive information with three dots):
*** Assembly Binder Log Entry (16/06/2013 # 15:45:12) ***
The operation failed.
Bind result: hr = 0x80070002. The system cannot find the file specified.
Assembly manager loaded from: C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll
Running under executable C:\Users\....
--- A detailed error log follows.
=== Pre-bind state information ===
LOG: User = ...
LOG: DisplayName = Microsoft.VisualBasic.PowerPacks.Vs, Version=10.0.0.0, Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a
(Fully-specified)
LOG: Appbase = file:///C:/Users/......
LOG: Initial PrivatePath = NULL
LOG: Dynamic Base = NULL
LOG: Cache Base = NULL
LOG: AppName = MSystemAdmin.exe
Calling assembly : MSystemAdmin, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null.
===
LOG: This bind starts in default load context.
LOG: No application configuration file found.
LOG: Using host configuration file:
LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework\v4.0.30319\config\machine.config.
LOG: Post-policy reference: Microsoft.VisualBasic.PowerPacks.Vs, Version=10.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
LOG: GAC Lookup was unsuccessful.
LOG: Attempting download of new URL file:///C:/.../Desktop/Microsoft.VisualBasic.PowerPacks.Vs.DLL.
LOG: Attempting download of new URL file:///C:/.../Desktop/Microsoft.VisualBasic.PowerPacks.Vs/Microsoft.VisualBasic.PowerPacks.Vs.DLL.
LOG: Attempting download of new URL file:///C:/.../Desktop/Microsoft.VisualBasic.PowerPacks.Vs.EXE.
LOG: Attempting download of new URL file:///C:/.../Desktop/Microsoft.VisualBasic.PowerPacks.Vs/Microsoft.VisualBasic.PowerPacks.Vs.EXE.
LOG: All probing URLs attempted and failed.
It isn't that clear why PowerPacks is missing, the .NET 4 Client Profile could be an issue. There have been multiple versions of PowerPacks around and the version numbering got to be a mess. On my machine, that same version is reported as v2.0.50727, even though it is stored in the GAC as version 10.0
Best thing to do is to go back to your project. Click the "Show All Files" icon on the toolbar in the Solution Explorer window. That now shows the References node. Expand it and select the PowerPacks reference. In the Properties window, change the Copy Local property to True.
Rebuild and your build directory now will have a copy of the DLL. Copy it along with the EXE onto the target machine.
Here is the URL to download Microsoft Visual Basic Power Packs 10.0
http://go.microsoft.com/fwlink/?LinkID=145727&clcid=0x804
Apparently, it seems to be a problem with the "PowerPacks"; these are additional controls to the ones given by default in Visual Studio (in the form design part, under "Toolbox"). If you install the required package on the target computer, everything should be fine.
I had this problem in the past and my recommendation is not relying on these elements: they include nice-to-have features (in my case, it was an elliptic shape) but might be replaced with a bit of work and simpler objects. If you want to sell your program to a more or less wide audience, relying on this might become a problem: this package is not installed by default on virtually any computer and thus you would have to ask your clients to go ahead with the installation. Locating these specific controls is straightforward: on the "Toolbox" they should be listed under "PowerPacks" or similar.
After reading the Hans Passant's comment, I do recall that a .dll file has to be put in the same directory than the executable, but I am under the impression that the PowerPacks package from the provided link has to be installed anyway (at least, on computers not having Visual Studio).
I was upgrading Visual Studio from Visual Studio 2013 to Visual Studio 2015 on a new Windows 10 machine. In doing so I copied my Projects folder from a Windows 7 machine to the same path on the Windows 10 machine.
When I opened a project which used MS.VB.PowerPacks.VS I was informed the file could not be found. I downloaded the newest install for MS.VB.PowerPacks.VS Version 12.0.0.0. Visual Studio 2015 blanked out my form pages which used the PrintForm and informed me:
System.IO.FileNotFoundException: Could not load file or assembly 'Microsoft.VisualBasic.PowerPacks.VS, Version 10.0.0.0.
I changed the reference to vcersion 12.0.0.0, but it was still not recognized.
My fix: I copied the the C:\Program Files(x86)\Reference Assemblies\Microsoft\VBPowerPacks\v10.0 folder from my Windows 7 machine to my Windows 10 machine, and then removed the v12.0.0.0 reference and added the v10.0.0.0 reference to the program. I then exited the project and opened it again, and all was well, the forms were displayed in their original beauty.

MsBuild and FxCop problems

I'm trying to make a build file to run with msbuild using cmd or jenkins build job.
The structure of the project is
the demo is here: www.saramgsilva.com/wp7/sarasilvademo.rar
Now i have 3 diferents ways to run fxcop, but i have problems in all.
1) In cmd go to the root file and then run
C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe .\SaraSilva.WP7.build /target:FxCop
this show a error: exit with code 128
2) In cmd go to the root file and then run
C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe .\SaraSilva.WP7C.build /target:FxCop
this doesn't create the buildartifacts\FxCop\FxCopAnalysis.xml file.
3) In cmd go to the root file and then run
C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe .\SaraSilva.WP7.build /target:TestWithCoverage
and
C:\SaraSilvaDemo\tools\FxCop-1.36\FxCopCmd.exe /file:C:\SaraSilvaDemo\buildartifacts /directory:C:\SaraSilvaDemo\buildartifacts\ /rule:C:\SaraSilvaDemo\tools\FxCop-1.36\Rules /out:C:\SaraSilvaDemo\buildartifacts\fxcop-result.xml
the result is:
Microsoft (R) FxCop Command-Line Tool, Version 1.36 (9.0.30729.1)
Copyright (C) 2007 Microsoft Corporation. All rights reserved.
Loaded DesignRules.dll... Loaded GlobalizationRules.dll... Loaded
InteroperabilityRules.dll... Loaded MobilityRules.dll... Loaded
NamingRules.dll... Loaded PerformanceRules.dll... Loaded
PortabilityRules.dll... Loaded SecurityRules.dll... Loaded
UsageRules.dll... Could not load Cimbalino.Phone.Toolkit.dll. Could
not load GalaSoft.MvvmLight.Extras.WP71.dll. Could not load
GalaSoft.MvvmLight.WP71.dll. Could not load
Microsoft.Phone.Controls.dll. Could not load
Microsoft.Practices.ServiceLocation.dll. Could not load
mscorlib.Extensions.dll. Could not load NLog.dll. Loaded
nunit.framework.dll... Loaded SaraSilva.WP7.AllTests.dll... Could not
load SaraSilva.WP7.App.dll. Could not load SaraSilva.WP7.Model.dll.
Could not load SaraSilva.WP7.SampleData.dll. Could not load
SaraSilva.WP7.SchedTask.dll. Could not load SaraSilva.WP7.Service.dll.
Loaded System.Core.dll... Could not load System.dll. Could not load
System.Windows.Browser.dll. Loaded System.Windows.dll... Could not
load System.Windows.Interactivity.dll. Could not load System.Xml.dll.
Could not load TombstoneHelper.dll. Initializing Introspection
engine... Could not resolve reference to System.Net. Analysis
Complete.
NOTE: One or more referenced assemblies could not be found. Use the
'/directory' switch to specify additional assembly reference search
paths.
Analysis was not performed; at least one valid rules assembly and one valid target file must be specified.
2 total analysis engine exceptions. Writing report to C:\SaraSilvaDemo\buildartifacts\fxcop-result.xml... Done.
I donĀ“t know what to do :(
The answer is to add the following switch to the command line to tell FxCop to search the GAC for assemblies:
/gac
Although I'm using FXCop 10.0 the error code you put are similiar:
NOTE: One or more referenced assemblies could not be found. Use the '/directory' switch to specify additional assembly reference search paths.
hence, for my case I modified FxCopCmd.exe.config file and change AssemblyReferenceResolveMode from StrongName to StrongNameIgnoringVersion
This is to ensure that it doesn't trying to find specific version of referenced assemblies
also make sure in Visual Studio the dll properties is having Copy Local = True