In VS2005 I have a few C# projects that depend on each other.
If project A depends on B (e.g. references it), then I want B to build whenever I build A, assuming B has changed in some way since last built. That's the way it is with VC projects, but for some reason it doesn't seem to work with C# projects. If I clean B and then build A it just tells me that it can't find B...
Any ideas?
If you right-click on your Visual Studio Solution and choose "Project Build Order" you can verify the order in which those individual projects are being built. ALSO make sure that you aren't referencing a "debug" DLL in a "release" build and vice versa.
You need to build the actual solution not the projects individually.
A Solution lets you define Dependencies between Projects. And if you use that, it should work automatically. Normally the dependencies are set up automatic too. Chances are you added a reference to the assembly, not the project. Watch the Projects tab in the Add reference dialog.
If you add all the projects to the same solution and set up the dependencies between them then Visual Studio should be able to work out the correct order and build everything that needs building when you change something in one of the "lower" projects.
In your case it would know that it had to rebuild B before building A.
override the target AfterResolveReferences in your csproj. Then use the item #(NonVCProjectReference) to list the path to every project and build them.
I recommend you to read the MSBuild documentation
Related
While doing some refactoring of our projects and solution files, i have separated some .sln files to contain less projects.
Occasionally i need to reference some projects from outside the scope of the current .sln file.
For example, my initial state was this:
SOLUTION A
PROJ A
PROJ B
After refactoring it would look like this:
SOLUTION A_NEW
PROJ A
SOLUTION B_NEW
PROJ B
My question is -- Is it possible to add a ProjectReference node to a project that is not defined in the same VS solution? (in my case, having PROJ A have a project reference to PROJ B).
Also, if it is possible, is that recommended?
I know that this is not possible from the VS IDE, only by editing the .csproj file manually.
You can't do this. A project reference includes an identifying GUID for the referenced project, which is maintained in the solution file in order to track solution build options and dependencies. If you try to reference a project that is not in the solution, Visual Studio will complain.
You can add a file reference to the assembly produced by a project that's not in the solution, of course.
UPDATE: Since this got downvoted, I'll refine my answer.
Though it's technically possible to craft a project file that references another project outside the same solution, Visual Studio won't help you to do it easily. One very good reason why it's a bad idea to do this (that I've observed) is that whatever Solution Configuration and Platform you're building (the referencing project) will be ignored if MSBuild decides to build the referenced project - the default Configuration and Platform specified in that referenced project file will be used instead. Thus you may end up with a mixture of binary types in different folders.
Temporarily add the project to the solution, add a reference to it, unload the project that now has a reference added to it, remove the referenced project, reload the project with the reference.
If you don't unload the project then the reference will be automatically removed by Visual Studio when the referenced project is removed.
As you can probably tell, Visual Studios not designed to do this and you'd be better defining a build order for the solutions and use assembly references instead.
You can definitely add a project to a solution A that is in solution B. There is not any problem with that. From my experience, it's not something that I usually have done or do, but sometimes need to. This can be especially true on large projects where you need different nodes of your architecture to reuse same code base.
Hope this helps.
We are doing a project that uses interfaces and Unity to resolve concrete implementations of classes.
My questions is the following: I need to get my dll's all into the same folder otherwise unity will not be able to resolve the interface etc. So according to me I have a couple of options:
1. Add the projects with the implementations as references and let VS copy the files to the output folder (for some reason this just feels like a hack)
2. Change the build location of all my projects to build to the same folder
3. Create a post build event to copy all the files needed to whereever they need to go
I have implemented to second option but this could lead to files in your build folder that should not be there. I am not a big fan of post build events, so I would like to ask from other people using Unity what they found to be the best solution for them.
Thanks in advance
The first approach sounds like the right one to me. Your project does depend on the implementation libraries; it doesn't express that dependency directly in code, but it requires them, so it seems reasonable to add a reference to them.
This is basically the same situation as where you've got three projects, where project A depends on project B, which depends on project C - you need to explicitly add project C as a reference within project A. Visual Studio doesn't work out transitive dependencies for you (at least it didn't the last time I checked).
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.