CIn our .NET application we have project A that reference an infrastructural project, let's call it Infra. Now, project A also references project B, which resides in a different solution, referencing another version of the Infra. The top level application, project C, references project A.
While this compiles just fine, it has another side effect - it does not copy the Infra.dll to the bin folder of project C.
I increased the verbosity of the build output, to see what exactly is the problem, and saw this:
There was a conflict between "Infra, Version=1.1.14.9..." and "Infra,
Version=1.0.0.0 ...". "Infra, Version=1.1.14.9" was chosen because it
had a higher version.
That actually makes a lot of sense, having 2 conflicting references to the same version should try to get the higher version. The problem is that B project's reference to Infra is not an accessible path and therefore will not be copied.
I could surly solve this issue by adding a reference form project C directly to infra, but I would prefer not to. I was wondering whether I could tell the compiler explicitly which version to use.
Any ideas?
Related
I have two C# projects, A and B, in VisualStudio 2010. Project A is a class library. Project B is a ReSharper-Plugin project that references project A (ProjectReference). Both projects compile and worked property when I ran project A in the Experimental Instance.
Now, recently I renamed a static class, with some extension methods, in project A. Both projects still compile. But when I run project B I get an TypeLoadException for the new class name. When I change the class's name back, everything works fine again.
My guess is that project B is compiled against the new code, but run against an outdated dll. I tried everything from clear, over rebuild, to restart, but to no avail. I also manually checked that a fresh dll from project A is placed in project B's bin/Debug folder, which is the case. And I copied over the dll manually, after building project A. The problem persists.
Now I ask myself whether there is another location where the dlls are copied to before running the Experimental Instance. Is this the case? If so, where to? Are there any other places where the old version could come form? Or is there even something completely different that could cause the problem?
Thanks in advance!
Ok. Did you reference the DLL or the Project? In a Visual Studio Solution you can reference projects. If you reference project A in project B then B should always use the latest code from project A.
I managed to figure it out myself, thanks to the right keywords on Google (MissingMethodException and ProjectReference) that led me to a blogpost about a solution to the same symptom. In my case it was not the GAC that caused the problem, but the cached assemblies under
C:\Users\{name}\AppData\Local\Microsoft\VisualStudio\10.0Exp\
This is the location where all the assemblies of the Experimental Instance go. Here lay an outdated VsExtension that depended on project A and within it there was an outdated copy of project A that was loaded. The loading of the new version from the project reference was simply skipped, since a copy of the assembly (with the same version) was already loaded.
So the problem was ultimately caused by the removal of the extension from my solution. From this point of the extension was no longer updated by VS, but it was also not removed! Lessons learned: After major changes of your infrastructure you may want to delete all cached assemblies below the above path...
Thanks for the help, everyone!
I have a project (call it A, it's an exe) which references another project (call it B, it's a class library) which references a dll (call it C). When debugging A.exe from visual studio I get a run time error:
An unhandled exception of type 'System.IO.FileNotFoundException' occurred in B.dll. Additional information: Could not load file or assembly 'C', Version=0.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified.
When I go to my executing bin\debug directory, sure enough, C.dll isn't there.
I've explicitly called classes in C.dll from B.dll, so there isn't any weird run time adding of references or reflection being used to call it. I've also set "Copy Local" to true on C.dll. If I reference C.dll from A.exe directly, then it runs with no problem, but I'd rather not have to do that.
I've tried to repro the problem in a new solution, but I've been unable to.
Does anyone know what might be preventing this dll from copying to the final output directory?
The best thing you can do is have the projects A, B, and C all in one Visual Studio Solution, then you can reference the other projects that you need without referencing the dlls.
Once you have that, then add a Project Reference like this:
project B references project C
project A references project B
Because you are then referencing the projects, it will pull the necessary dlls along for the ride when you compile the whole thing.
However, as neo said, if you keep C as a dll, then A will have to reference it as well, because VS is not smart enough to copy it as well.
I've encountered similar problems so I'd recommend to try these things:
Toggle "copy local" to "false" and then to "true" again, it should resolve the problem, if the problem is missing
< Private > True < /Private > node in project file
Check Target Framework of your project, I'have similar problem with several projects targeted "4.0 framework" and other "4.0 client profile", after switching to "4.0" on every project was resolved
Ok finally got it...I think.
It looks like the C project didn't have any version information under Application-->Assembly Information. It was also missing a guid.
For the record: You CAN reference the way I described (A refs B which refs C) and have the output copied. I did go back to a dll reference rather than a project reference and it still worked after a clean and build.
I'm still not sure why I was able to get this to work in a new solution (before making changes), but I'm up and running now.
Edit:
One other note, it looks like there was no assembly.cs in the project (which is why it didn't have any version info). I wonder if it was just a recompile of this project that could have fixed it rather than updating the assembly info.
I have got a Visual Studio Solution containing several projects and have set up the references between the projects as project references.
When a reference to an assembly is added, the references' properties contain a setting for
Specific Version = True|False
This property is missing for project references. How can it be set? I'd like my solution to load any available assembly (no matter what version) in the bin folder.
I've had a problem when a workflow instance (Workflow Foundation) was deserialized and the dependencies were updated meanwhile.
I think the problem is that what you are asking is not possible directly with a project reference, I think that always implicitly turns into an 'explicit version', because of the nature of the link.
The way you could do this (calling the currently referenced project A, and the referencing project B):
Have the project you want to reference in your solution, just like you do now with the project reference
Explicitly set the dependency chain so the 'referenced' project is built first
Build the referenced project A once first manually
Create an assembly reference in project B to the results from the build in project A
Set the assembly reference to 'Specific Version = false'
The build order (dependency) will guarantee that A is always built before B, and B will reference it from the binary output directory of A.
(altho, it's a little brittle and I would not recommend it since it's easy to get wrong results if the settings are not all right, or the sun aligns with the stars wrong, or some such)
I might be misunderstanding your question, but when you add a project reference, the project's assembly is always loaded into any project that references it when the project is built. Therefore, you'll always have the latest available assembly in the bin folder for that project. VS treats projects differently than other assemblies in that regard.
You can add references to project output dlls instead of projects. Then you will be able to set Specific Version setting.
I have found the solution to my problem. It's described pretty detailed here.
The problem is not a matter of wrong project references, but more a de/serializing of workflow instances question.
Thanks to everybody who tried to help.
If I have an assembly (A) which references another assembly (B).
I want to reference A in a project, I add the reference and it copies A into my BIN directory. It does not copy B as well, even though A depends on it, so the code doesn't compile.
How can I set things up so that whenever I reference A, both A and B get copied to my bin directory?
In Visual Studio, add each project to the same solution. Ensure you use Project References instead of direct file references (ie browsing for the assembly).
I dont think there is any way around what you ask other than to explicitly add both. I dont think however adding projects for the sake of getting references copied is a viable solution to the issue. Not all projects that a solution depends on should necassarily be added to the solution. This would completely depdend on your overall project structure, processes, source control, division of labour, etc
Reference both A and B.
Unfortunately you'll have to manually add both. This is what happens to me as well whenever I use pre-3.5 versions of NHibernate: it requires both log4net and Iesi.Collections assemblies. So I have no choice but to manually include a reference to both in all my solutions that implement NHibernate.
This is more of an issue, of course, if you only have the DLLs. If it's a project that you have a codebase to Visual Studio itself will warn you beforehand that the references are missing.
How about adding them to Global Assembly Cache?
I'm probably asking this question wrong (and that may be why Google isn't helping), but here goes:
In Visual Studio I am compiling a C# project (let's call it Project A, the startup project) which has a reference to Project B. Project B has a reference to a Project C, so when A gets built, the dlls for B gets placed in the bin directory of A, as does the dll for C (because B requires C, and A requires B). However, I have apparently made some change recently so that the dll for Project C does not go into the bin directory of Project A when rebuilding the solution. I have no idea what I've done to make this happen.
I have not modified the setup of the solution itself, and I have only added additional references to the project files. Code wise, I have commented out most of the actual code in Project B that references classes in Project C, but did not remove the reference from the project itself (I don't think this matters). I was told that perhaps the C# compiler was optimizing somehow so that it was not building Project C, but really I'm out of ideas. I would think someone has run into something similar before
Any thoughts? Thanks!
Have you changed your build configuration? In Visual Studio 2008, the default Solution Configurations are Debug and Release while the default Solution Platform is Any CPU. My experience suggests the Solution Configuration/Platform pair has a unique build configuration. In other words, Debug/Any CPU and Release/Any CPU are two independent build configurations, each with their own settings. If you've selected a different configuration, the settings for the original configuration do not automatically apply; you'll need to set the dependencies for all of your configurations, as well as any new projects you add to your solution, in order to seemlessly switch between them.
You can right click on the solution in the solution explorer, and check your project dependencies.
My guess is that, somehow, you've flagged that B doesn't rely on C.
Alternatively: In the solution properties, make sure that the current Configuration is set to build Project C.