A have a large web service solution (written in C# targetting .NET 3.5) which is comprised of 16 individual projects (many class libraries, a few web applications and setup projects). It is developed in visual studio 2010.
I was recently experimenting with Microsoft.CodeContracts, and after evaluating it decided that it was not suitable for my needs. I removed all of the code that referenced it, and removed the assembly references from all of the projects that referenced it.
However my web service has now started to randomly return this error message:
"Could not load file or assembly 'Microsoft.Contracts, Version=1.0.0.0, Culture=neutral, PublicKeyToken=736440c9b414ea16' or one of its dependencies. The system cannot find the file specified."
How/Why can it still be trying to load that assembly when I have removed all the code & references to it?
On investigating further, I am still finding that Microsoft.Contracts.dll is showing up in the /bin/ folder of my web application, even though no projects reference it. It is also listed as a "detected dependency" in my setup project - but I am 100% certain NONE OF MY PROJECTS ARE USING IT!
This is driving me absolutely nuts - there is obviously something lurking around thats holding the reference. How can I remove all traces of Microsoft.CodeContracts from my solution?
There are numerous XML elements within CSharp project files that start with CodeContracts.
Remove them if you feel you need to do so.
There will be as many sections as you have configurations {Release, Debug} x {Any CPU, Mixed Platforms} = 4. Do this for each *.csproj file in your solution.
Keep in mind that CodeContracts conditionally generate/weave code, so you app might behave differently.
Related
I'm working on a really old program for my employer that requires a manifest file. Unfortunately the project was developed in .Net 2.0 on VS 2005 (Academic Edition) and migrating/updating to a newer... whatever would be time consuming and the really not worth it.
I've found ways to add a manifest file to a .exe manually (which is kind of a headache and I would prefer to avoid that route if that is at all possible for me to automatically include a manifest file into the application? I've found a few things on it but the options they reference seem to be missing from the Academic Edition.
I've seen this direction but there doesn't seem to be a manifest tool node (or I'm doing it wrong, could be either one). I found some images the closest I could get was this:
And it's missing the Manifest node that was referenced.
Is this possible to do with Academic Edition, or am I just hosed into having to do it the Open .exe in VS/add as a resource method? If I have to do it that way, that's fine but if there's a better way then I would prefer the better way.
I have a VS2010 C# project, that references a large set of native .dll's (a commercial java runtime). These file are referenced as 'Content' files in the project, since the need to be copied with the project.
The code in these libraries is called using PInvoke, there is no assembly reference.
Every time I compile the solution, the Visual Studio testing framework tries to load all the referenced dll files, expecting to find .net assemblies which may contain unit tests. Since the are no .net assemblies, the following exception is thrown:
Error loading some.dll: Unable to load the test container 'e:\some.dll' or one of its dependencies. If you build your test project assembly as a 64 bit assembly, it cannot be loaded. When you build your test project assembly, select "Any CPU" for the platform. To run your tests in 64 bit mode on a 64 bit processor, you must change your test settings in the Hosts tab to run your tests in a 32 bit process. Error details: Could not load file or assembly 'file:///e:\some.dll' or one of its dependencies. The module was expected to contain an assembly manifest.
This takes a whole lot of time, and I would like to tell Visual Studio to not try to load these files.
How can I tell Visual Studio to stop trying to load these files?
Correct me if I got this wrong:
You are including the P/Invoke target binaries in to the VS solution because you want the binaries to be copied over to the target directory when the solution is built. You want this because the project will execute from the target directory as soon as the VS solution is built. Correct?
Often times VS packages (both default and 3rd party) try to get smart about the solution content and will follow certain triggers (which are difficult to contain and control by ourselves) and load the solution and project content in their own ways. Fighting the battle in this area has poor ROI than employing a simpler work around (below).
While I can't provide you with an authoritative answer on how to tell VS's test package to not load all binaries, I suggest removing such binaries from the project as 'content' and leave them in your source control where they are today. Add a post-build task that will copy the said binaries over to the target. This will still give you the same result as it is working today but, takes those binaries out of reach for the test probes.
You must check out configuration settings by just right clicking on your solution name and click on "Configuration Manager"
It will open a pop up window for Configuration Manager.
Check not for the platform your projects are using it is better to choose any CPU.
Hope this can help.Give it a try:)
Because thats what your exeception says as you have quoted
Thanks
I tried to repro this issue and found that the root cause is that you have set your test project to be compiled as !AnyCpu. Is there any particular reason why you would want this for managed test code?
So unless you change this you will continue to see this message.
If you want to continue using this configuration for your test project you would need to update your .testsettings file as suggested in the message.
Sorry if this seems remedial. I am including it for the sake of completeness.
General library behavior
A library can be referenced either in the project file (and so the compiler injects to code to load the references) or dynamically at runtime with LoadLibrary() or PInvoke calls. When a referenced library is loaded, a function at the entry point is run can in turn load any libraries it depends on. When loading the library, there is a well-known set of paths that Windows will search, including %WINDIR%\Assembly and the current directory. There's a lot of good conceptual information on Wikipedia about this. I recommend reading it.
Possible Root Causes
I can't tell from your question if you are having trouble building the application, building the tests, or executing either. Generally I would not expect PInvoke to cause compile errors.
Error during app build: VS generally will show you that you have a reference to a DLL it can't find. However, you may be missing a DLL that is needed to satisfy all the dependencies. To resolve, just add the reference to the missing DLL. (This is the simplest issue, so I'm guessing this isn't what you're seeing.)
Error during test build: Since your test will reference your application/library, it also needs to have the same reference. Usually the easiest way to ensure you are getting everything is to remove all references and add a reference to the project you are testing. It's possible you some additional libraries are necessary for some tests, but not your app/lib itself. These need to be added separately.
Error during app execution: This can happen when starting the application, or later when an call to the external library is made if late binding is used.
Error during test execution: This can happen the same as with app execution. However, tests can also be "partially built" to only execute a small number of tests. In these cases, some files may not be copied. Using the [DeploymentItem()] attribute, you can specify that a test requires the presence of certain files in the test or app/lib project to function. MSDN describes how this can be done.
Resolution
For #1 & #2 the solution lies in adjusting the references in the project.
For #3 & #4, it may get trickier. There is a similar question to yours regarding Windows Mobile here which you may find useful, especially referring to using dumpbin to list out library dependencies. You can also use procmon from SysInternals to monitor file access during compile or load to see which files are not found. Then you can either include the missing file, or remove the library referencing it.
Good luck. Hope this helps.
We have recently taken over a project from an outsourcing company. This project uses Moles and Pex for unit testing, but since we have not had the project for long, I am not very familiar with the frameworks.
That being said, we are busy upgrading this project to run in .Net 4. I have resolved most of the issues that have jumped out, but there is one that I cannot get a handle on. Some of the unit tests cannot compile because of the error:
Could not load file or assembly 'Example.Assembly, Version=0.0.0.0,
Culture=neutral, PublicKeyToken=null' or one of its dependencies. The
system cannot find the file specified.
The part that baffles me is that it is a project reference and the assembly is being copied to the output directory of the unit test. Most of the other project references are found and I cannot spot any difference between the ones that work and the ones that do not. I am not sure if this problem has to do with the pex/moles frameworks, but I thought I would mention it.
I have tried the usual things of removing and adding all the references and regenerating the moles assemblies.
Has anyone else run into this problem? Any help would be greatly appreciated.
EDIT1: Ok, after some more investigation into the build output, it appears as if it is not moles, but the .accessor files that are not generated correctly. I get the exact same problem as asked in Unit test project cannot find assembly under test (or dependencies), but unlike his problem, mine does not go away after deleting the accessor.
EDIT2: Turns out is is a program called Publicize.exe which falls over with that error. Still no idea why though. Looking at Fusion logs is looks like it does not search under the working directory for the dll that it is trying to generate the accessors for. Running it manually on a bunch of assemblies from our solution, I find it works on some, but not on others. I have not been able to identify a difference between the ones that work and the ones that don't, though.
Thanks
Ah, yes. I have read this story many times, and have the tee shirt. I run through my usual Moles first-aid kit, when encountering any issue, including this one.
Perhaps, this question will provide some help: Am I the only one getting "Assembly Not Available in the Currently Targeted Framework"?
Ensure the Moles framework is properly installed on the workstation and/or build server
Ensure the Moles assemblies are being built (see the excluded "Moles Assemblies" directory)
Check your build profile -- it may need to be set to full framework profile
Triple check your output destinations and post-build commands -- I have seems some solutions that copy the output to another location
Try using the Visual Studio Pex/Moles extension, if you are not already doing so
An invasive fix-all process is to simply create an all-new solution, projects, and test projects, and then copy the existing code files into them. It's surprising how many issues can be resolved for various project-related errors. Basically, a hard reboot for the entire solution.
Since you are updating to .NET 4, you may as well go to 4.5, and used the productized version of Moles, called "Fakes". You'll find Fakes in the Visual Studio 2012 release candidate. This significant feature hasn't received much attention.
I opened up VS today to find this error waiting for me when I built my project. I hadn't changed anything since yesterday, when it was working just fine.
Unable to load arguments for the XmlPeek task. One of XmlContent or XmlInputPath arguments must be set.
Of course this error has no line associated with it or anything else that may be helpful...
The project is in the .NET 4 Framework with Console Output.
Any ideas as to what is going on? I tried googling this of course but the few answered I found had to do with a content pipeline (which this project does not use).
Thanks!
I received this error in case, when I have deleted Content Project of my game. It has been solved by adding correct content reference into the Content References directory.
I had two projects (proj1 and proj2) and each of them had their own content projects (proj1_content and proj2_content). I wanted to have one common content project for both projects, so I had deleted both proj1_content and proj2_content and created new content project called common_content. After that, mentioned error appeared. Solution was to go to Content References directory at each project and Add Content Reference pointing to common_content.
Due to a hardware problem I had to put in a new SSD and re-installed VS. All my projects worked except my XNA in Winforms project. Being rather large (12,000 hand-written lines of code) really didn't want to try the "copy it all in to a new project" solution above. Thought I'd try to see what versions worked. All versions prior to me adding an installer project worked. In fact, the version where I had added, then deleted the installer was broken. So I'm not sure how (or if) the installer broke it but I found one section of the main project file that had a missing entry and it did reference XNA also (all my non-XNA projects build just fine). Note that I have substituted my project's name with a reference to YOUR projects name by using <YourMainProjectName>. If your project is joesgreatproject then use that text in place of <YourMainProjectName> (don't include the <> symbols). I think this was only because the XNA didn't have a content directory and needed a reference to one.
File: <YourMainProjectName>.csproj
<ItemGroup>
<ProjectReference Include="..\< YourMainProjectName>Content\<YourMainProjectName>Content.contentproj">
<Name><YourMainProjectName>Content</Name>
<XnaReferenceType>Content</XnaReferenceType>
</ProjectReference>
</ItemGroup>
I have an issue where all my xaml views are saying there is a bad reference to System.Windows.dll. I ran ProcMon and realized it was looking for the dll's in the GAC. I started a new project, and it's looking for the dll's in the right spot (the Windows Phone 7 Referenced Assemblies folder).
All of my other projects are referencing fine (but this is the only one with views in this solution, other views work fine in other solutions). I'm pretty sure it's something to do with VS2010's assembly cache, or possibly SxS, but I can't figure it out.
Anyone have an idea? I don't want to GAC the libs, since that'll bring up other errors, I just want it restored to the way it was.
Here's the error I see in code for all my xaml pages.
Warning 1 Could not load file or assembly 'System.Windows, Version=2.0.5.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e' or one of its dependencies. The system cannot find the file specified. C:\Users\myUser\Desktop\MySln\MyApp\App.xaml 1 1
Thanks!
You can just expand the References folder in your project and remove the defunct reference and add the right one?!