Moles seem to choke when I try to mollify a certain DLL. It exits with the error code -1 and the messages would say:
cache: failed to compute assembly metadata hash
code: failed to generate stub type for ... (a bunch of this)
Also, setting Diagnostic=true and Verbosity=Noisy only seem to work if we have 1 .moles file. If we have more than 1 DLL to mole / multiple .moles files, we still get a somewhat 'summarized' output view - which will not expose any errors / warnings during the generation of moled DLLS - causing us to wonder what went wrong.
Finally, the DLL can be consumed consumed by the actual application code without any visible issues, except when putting it through Moles.
I can accept if the DLL is somewhat faulty, but what could be the reason behind these messages when the symptoms only exist in Moles?
I am using the latest version of Moles ( v0.94.51023.0).
I don't know what causes this, but to fix it I usually have to remove both the Moles AND the original assembly reference before re-adding and re-building.
Related
I'm trying to update a Unity project that was built in version 2019.4.01f (Intel, LTS) to version 2021.3.10f (Apple Silicon, LTS). The reason is that I need update the In App Purchases package from Unity because Google Play requires that I update the billing library.
I already tried a bunch of options, but I keep getting errors. If I generate the GoogleTangle I get error CS0103: The name 'Obfuscator' does not exist in the current context. If I don't generate new tangles or copy the old tangles from the old path to the new one (according to the steps from here), I get other errors like: error CS0234: The type or namespace name 'Purchasing' does not exist in the namespace 'UnityEngine' (are you missing an assembly reference?) and other similar errors. If I manually add some of the Purchasing assembly definitions I see no improvements.
Did anyone tried doing this recently?
The reason for the error was an Assembly definition. In order to allow PlayMode tests access to some of the game code I had an Assembly Definition in Assets/Scripts that was referenced in the PlayMode Assembly.
After removing the tests and the Assembly definition, the errors went away except for a new one that lets you know that you need to initialise Unity Services before initialising Purchasing (that's how Unity Purchasing works now).
This was a quick fix. The correct solution would be to keep the tests and use Assembly definitions in the folders that contain the code that PlayMode tests need to access. That will most probably lead to the need of Assembly definitions in other folders as well and at this point the code structure must be built in such a way that you don't get cyclic references between Assembly definitions.
I am playing around with Microsoft's Q# library, and I've gone through the install, however the build is failing and I am having a tough time figuring out the problem. My first suspicion is Microsoft.Quantum.Canon
EXEC : error QS1001: Assembly E:\Projects\Quantum\Microsoft.Quantum.Canon\bin\Debug\Microsoft.Quantum.Canon.dll not found
I also have noticed Microsoft.Quantum.Canon.nuspec is missing. I've tried to do a Nuget.exe restore on the solutions but that did not work.
Has anyone worked through this?
It's been reported on GitHub already, although it appears to be intentional. See the comments in the .gitignore file:
# These files are generated by bootstrap from a .v.template (version template).
# Any changes must be done to the corresponding the .v.template file directly
Microsoft.Quantum.Canon/Microsoft.Quantum.Canon.nuspec
I can't find any info on this .v.template file, probably it's part of internal Microsoft build tooling. You can copy the template file and fill in the missing parameters if you wish, but the file not existing doesn't make the build fail , does it?
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....
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.
Well we are facing a strange problem with JetBrains TeamCity induced unit tests on our main project where tests from few library projects are failing regularly. Apparently, it's not reading the config file (coming from app.config and nicely stored in project -> bin -> debug -> projectName.dll.config).
Hints or tips on what could be the real issue would be highly appreciated.
I've got the same problem and wasted a couple of hours to figure out what the problem is.
In our case, the NUnit plugin was configured to run the tests from:
**\*Tests.dll
Though this sounds to be OK, it has turned out that this pattern will not only match to the MyTests.dll in the bin\Debug folder but also to the obj\Debug\MyTests.dll. The obj folder is used internally for the compilation and does not contain the config file.
Finally the solution was to change the plugin configuration to
**\bin\Debug\*Tests.dll
Actually we use a system variable for the build configuration so we did not have the "Debug" hard-coded. Using bin* might be also dangerous when the workspace is also used for Debug/Release builds and you don't have a full cleanup specified.
You might wonder why I did not realize the test count mismatch (actually it was doubled, because they were running once from bin and once from obj), but this is typical: while everything is green, you don't care about the count. When we have introduced the first test depending on the config, we had only one failure (because the one from bin was passing), so the duplication was not outstanding.
In addition to Gaspar Nagy's accepted answer, check to see if your project has multiple test dlls and one of them is referencing another.
This causes the referenced dll to be run twice, and the copy that was in the other dll's folder to not have the proper app.config entries. The proper fix is to remove any and all references from the other test project.
TeamCity (v6.5.4) has its own NUnit Test Runner and there seems to be an inconsistency between it and the NUnit GUI test runner (2.5.10). The NUnit GUI Test Runner follows the long standing convention of expecting the configuration file name to be of the format .config. You can see this in NUnit by looking at Project -> Edit...
TeamCity on the other hand is looking for an app.config.
Your options are to either:
Set the NUnit GUI to point to app.config and include the resultant
nunit project in your source control.
Have both an app.config and a .config - syncing both
manualy.
Add a step to your build process to copy .config to
app.config (or vice versa).
I had similar woes
This may help; additionally we had issues where this still would not work - we ended up copying the relevant config sections into the highest level config file. (i.e. if it was a web app copy it into the Web.Config) - fairly kludgy but we had wasted a few days on the issue
I learned recently that app.config files are not read for a class library... Maybe this link could help :)
app.config for a class library
If you need a config file for your "unit" tests then you are doing it wrong. Proper unit testing never needs configuration or access to the database, file system etc. You should change your testing strategy.
Good point to start is mark your tests that need configuration with the[Category("Integration")] annotation and set the Teamcity test runner to ignore this category. Then you should focus on refactoring these test.