I have a NancyFX web project using SimpleAuthentication that works fine when self-hosting from the terminal. When I self-host from unit tests (NUnit runner with Xamarin Studio), I receive exception "Failed to reflect on the current domain's Assemblies while searching for plugin" with error message "Could not load file or assembly or one of its dependencies." repeated many times.
Any idea why this would fail? This looks like the code throwing the exception is at https://github.com/SimpleAuthentication/SimpleAuthentication/blob/master/Code/SimpleAuthentication.Core/ReflectionHelpers.cs. I tried a IntPtr.Size measurement to make sure they are running in the same 32/64 bitness in both cases (it is running 32-bit).
UPDATE: Per recommendation, I tried to run some prerelease builds to the same resulting, ending up with these binaries:
./Nancy.1.3-Pre1524/lib/net40/Nancy.dll
./Nancy.Authentication.Forms.1.3-Pre1524/lib/net40/Nancy.Authentication.Forms.dll
./Nancy.FlashMessages.1.0.4.0/lib/net45/Nancy.FlashMessages.dll
./Nancy.FlashMessages.Razor.1.0.4.0/lib/net45/Nancy.FlashMessages.Razor.dll
./Nancy.Hosting.Self.1.3-Pre1524/lib/net40/Nancy.Hosting.Self.dll
./Nancy.SimpleAuthentication.0.3.14/lib/net40/Nancy.SimpleAuthentication.dll
./Nancy.Viewengines.Razor.1.3-Pre1524/BuildProviders/Nancy.ViewEngines.Razor.BuildProviders.dll
./Nancy.Viewengines.Razor.1.3-Pre1524/lib/net40/Nancy.ViewEngines.Razor.dll
UPDATE: Running the ReflectionHelpers.cs code in isolation shows that the only DLL failing to load is MonoDevelop.NUnit. The NUnit dll is unneeded for this part anyhow.
I suppose I should contemplate https://github.com/SimpleAuthentication/SimpleAuthentication/issues/144
I fixed this with GetLoadableTypes from this post from #haacked http://haacked.com/archive/2012/07/23/get-all-types-in-an-assembly.aspx/
And here it's the PR (https://github.com/SimpleAuthentication/SimpleAuthentication/pull/171)
I didn't had the problem with Nunit I had the problem with Microsoft.Owin.Security.DataProtection.DpapiDataProtector that it's not implemented in Mono....
Related
Recently, I ran into an issue at work. To summarize it, I am currently working on writing test cases for an internal Flutter project. This had been working fine for a while, but after my summer vacation, it started breaking. It took me a while to figure out what roughly was going on, but I hen discovered that running integration tests generated a file named generated_main.dart under .dart_tool/flutter_build/. This was working just fine when using integration tests, however, it caused unit tests to fail due to not even loading.
I managed to identify the relevant line of code in the generated file as line eight: import 'file:///tmp/flutter_tools.WJSDQT/flutter_test_listener.YHXZLS/listener.dart' as entrypoint;. The capitalized strings of random characters are indeed random, apparently referring to a temporary path that only exists for the unit test's duration. Unit tests throw (even though not always reliably): .dart_tool/flutter_build/generated_main.dart:8:8: Error: Error when reading '/tmp/flutter_tools.WJSDQT/flutter_test_listener.YHXZLS/listener.dart': No such file or directory.
Surprisingly, there seem to be no issues when deleting the generated file. I have now added a print statement to the integration tests that tells whoever ran them that they need to delete the generated file. But this is obviously not a good solution long-term. Is there a way to disable this behavior so that testing does not become unnecessarily more complicated?
My environment is Ubuntu 20.04 LTS with Flutter 2.5.0-5.1.pre on channel beta, using Android Studio 2020.3.1. I am not currently able to test for this behavior on other platforms. The program needs to run on Linux. The test package version is 1.17.10, the newest one compatible with other dependencies.
Thank you in advance for your time.
I am getting error as mentioned Either assembly contains no tests or proper test driver has not been found.
When i enter "nunit3-console.exe project.dll".
I tried few solutions but it doesn't help me.
Assumming you have not found a new bug in the NUnit engine, then one of the two things in the message is probably true...
You are running an assembly that has no tests
You are running an assembly with tests for which there is no driver installed, IOW tests that the engine does not know how to run.
These two things are combined in one message because it's really all one thing to the engine, which is basically telling you "I can't find anything that looks like a test to me."
Most likely, you do not have any NUnit3 tests, because knowledge of those is built into the engine itself. So, I would guess you are either running NUnit V2 tests or tests from some foreign framework, like xunit or microsoft test.
For more of an answer, please tell us what kind of tests you are running. What testing framework (and version) do your tests reference? If you are running NUnit V2 tests, do you have the V2 Framework Driver extension installed?
So... maybe there is a bug in the NUnit engine.
I had this exact same error message on my build server. At the same time the tests were running fine in Visual Studio (2015 with Resharper).
This happened when I started converting existing xunit to nunit tests in an assembly. As soon as I removed the last xunit test, the error went away.
Try to comment out everything except NUnit tests to see if this fixes the problem for you.
I am stuck on this exception already for two days.
I am using MS CRM 2011, and got this exception when I try to register CRM custom worklow activity assembly
1. through pluginregistrator tool,
2. or when I deploy the plugin though package project in Visual Studio and after it run the the workflow, and it stops with waiting status, in the details page giving this expcetion. Here is the detailed exception:
Workflow paused due to error: Unhandled Exception: System.IO.FileNotFoundException: Could not load file or assembly 'Microsoft.Xrm.Client, Version=5.0.9688.1154, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The system cannot find the file specified.
at ArmenianSoftware.Crm.Spayka.ArmsoftIntegration.Workflows.CreateWorksByPlan.Execute(CodeActivityContext executionContext)
at System.Activities.CodeActivity.InternalExecute(ActivityInstance instance, ActivityExecutor executor, BookmarkManager bookmarkManager)
at System.Activities.Runtime.ActivityExecutor.ExecuteActivityWorkItem.ExecuteBody(ActivityExecutor executor, BookmarkManager bookmarkManager, Location resultLocation)
I am registering assembly on the file system, I have loaded all needed assemblies in the folder %system root%\C$\Program Files\Microsoft Dynamics CRM\Server\bin\assembly. This workflow worked some time, but after I don't know what, next time I deployed the assembly, I got this exception when executing the workflow. This is already third time I am coming across this problem, and spoiling several hours trying to do different things (IIS reset, Async Service restarts, reloading all the assemblies again and redeploying), and after several hours, in a mysterious way, the workflow starts to work. After this works some time, and after some redeployment crashes again. And I can't determine after exactly what steps I solve the problem, and so I spend always several hours on finding out the exception source but to no purpose.
I have looked through some threads in the web but none of them was my case (here are they thread1 , thread2 , thread3)
Have anybody come across this problem? What is the reason of this exception??
Thanks in advance!
I have found the problem in my case!
First thing I have noticed was that the in the Exception the required version of the Microsoft.Xrm.Client assembly was 5.0.9688.1154, but in my project I have the reference to the assembly of version 5.0.9689.1985.
And the next thing was the open ildasm tool, and look what referenced does it have, I opened my custom workflow assembly and I've found that I have two references to Microsoft.Xrm.Client,
first of version 5.0.9688.1154, and the second: 5.0.9689.1985
And a question arose "If I have referenced a assembly the version of wich is 5.0.9689.1985, why there is another version of this assembly? ". And the answer was, definitely, that I had another referenced assembly, which referenced Microsoft.Xrm.Client assembly with version 5.0.9688.1154. I have looked through the assemblies I have reference to in my project. And GOTCHA! In my project I have updated the SDK asseblies to a newer version, but I also had the generated CRM organization Proxy classes assembly, which references Microsoft.Xrm.Client, and I haven't updated this reference to a newer version of CRM SDK. So my custom workflow assembly also needed this version. I changed the references of Proxy dll to newer version, and everything went OK!
If you are reading this post, and you don't have proxy assembly, check your other assemblies, if they all reference the same version of the CRM SDK, if not correct them!
Regards
Gagik Kyurkchyan
I am evaluating PostSharp for a new project but cannot seem to get past the following error when I first build the project after changes:
Cannot copy file "C:\SourcePath\Output\Debug\MyApp.vshost.exe to
obj\Debug\Before-PostSharp\MyApp.vshost.exe: the file is locked by
process(es):MYAPP.VSHOST (8064)
The error only occurs in the first build attempt. If I immediately re-build, the error does not occur. I can only guess this is because the project isn't actually being rebuilt the second time.
I've read a few posts in the SharpCrafters forum that indicate this problem existed prior to v2.1 but was reportedly fixed. I am using v2.1.6.14 from NuGet (in VS 2010) and getting this error for every project I reference PostSharp. It is certainly not reasonable to require 2 builds every time, so I'm looking for a possible solution. I'm really pleased with what I've seen thus far but will have to go another direction if that can't be resolved.
UPDATE
Per Gael's request, I generated the diagnostic build log and sent it to him and it looks like he was able to resolve the problem in the latest release (2.1.6.14).
I believe part (or all) of the issue may be due to the fact that the build output for all of my projects is set to a common location (i.e. not the /bin/debug folder under each project). This is because we are using a MEF DirectoryCatalog which will discover Imports and Exports contained in the assemblies located in the output path. The PostSharp.targets file has the vshost.exe file excluded from the copy operation but only when it shares the name of the output assembly. In my case, the vshost.exe file has a different name and was, therefore, not being excluded.
The issue has been re-fixed in PostSharp 2.1.6.15.
My partner and I have a suite of tests running nightly on a build server for our project. We use CruiseControl.NET to run the server, and the tests are written using WatiN and NUnit. We have CruiseControl.NET running as a service with access to interact with the desktop on a local system account. Every few times that we run a build, certain tests will fail with error messages such as the following:
Test: cfarmweb.tests.Views.GeneralRegressionTest.DuplicateUsernameTest
Type: Failure
Message: SetUp : System.Runtime.InteropServices.COMException : Creating an instance of the COM component with CLSID {0002DF01-0000-0000-C000-000000000046} from the IClassFactory failed due to the following error: 800704a6. TearDown : System.NullReferenceException : Object reference not set to an instance of an object.
at WatiN.Core.IE.CreateNewIEAndGoToUri(Uri uri, IDialogHandler logonDialogHandler, Boolean createInNewProcess)
at WatiN.Core.IE..ctor(String url)
at cfarmweb.tests.Navigator.SiteNavigator..ctor(String browserName, Boolean visible) in c:\ccworkdir\CFarm\builddir\cfarmweb.tests\Navigator\SiteNavigator.cs:line 35
at cfarmweb.tests.Views.GeneralRegressionTest.MakeNavigator() in c:\ccworkdir\CFarm\builddir\cfarmweb.tests\Views\GeneralRegressionTest.cs:line 34
--TearDown
at WatiN.Core.Browser.OnGetNativeDocument()
at WatiN.Core.DomContainer.get_NativeDocument()
at WatiN.Core.Document.ContainsText(String text)
at cfarmweb.tests.Navigator.SiteNavigator.HasText(String target) in c:\ccworkdir\CFarm\builddir\cfarmweb.tests\Navigator\SiteNavigator.cs:line 213
at cfarmweb.tests.Navigator.SiteNavigator.SignOut() in c:\ccworkdir\CFarm\builddir\cfarmweb.tests\Navigator\SiteNavigator.cs:line 110
at cfarmweb.tests.Views.GeneralRegressionTest.DisposeNavigator() in c:\ccworkdir\CFarm\builddir\cfarmweb.tests\Views\GeneralRegressionTest.cs:line 123
The success of the builds does not seem to be dependent on changes to the code itself, as we have had builds break or be fixed after changes to parts of the program that are unrelated to the tests.
We are both new to the field of software testing (and development in general), but nothing we've found online about this error seems to pertain to our situation. We've seen everything from a system reboot pending to compatibility issues with Internet Explorer 8 to JavaScript errors, but nothing we've tried has fixed the issues. One of the most difficult parts is that it's not consistently reproducible. How can we fix this problem?
Ben,
I had the exact same issue, surprisingly enough...I think I have the solution. It appears to be a threading issue. The [RequiresSTA] tag at the top of a test is meant to create each test to be single-threaded by implicitly placing the tag [STAThread] on each method. However, I am inclined to believe that these tags are not being called on the [SetUp] or [TearDown] methods, creating threading issues. I have hopefully resolved the issue by placing the [STAThread] tag on each method (including the [SetUp] and [TearDown] methods) explicitly. I will let you know of any further changes, but it's worth a shot.
There are some similar issues related to Watin and IE8.
Running Watin on TeamCity
failed due to the following error: 800704a6 while trying to read data from a text file in teamcity
https://serverfault.com/questions/179156/ie8-script-error-800704a6
From what i understand, make sure you windows is fully updated, make another restart just to make sure and check if problem persist.
If it does, try runnning ccnet not in service mode.
If still no good, try to play with internet options security to determine if this affect the problem.
HTH