I have a large number of projects in my solution, but the main two that are of interest are projects A and B. Project A has no reference to project B. Here's what happens in a few scenarios:
Build project A. Project A builds as expected.
Run project A without debugging. Project A builds as expected.
Debug project A. Project A builds as expected, but build output gets wiped when complete and VS starts building project B.
Unload project B and debug project A. Project A builds as expected.
Based on these, I think I can safely say that there are no dependencies on project B from project A. I've also searched all the .csproj files, as well as the .sln file itself. There are no references to project B anywhere that I don't expect any (obvious by the namespace prefixes). What could be causing scenario 3 to rebuild project B?
Related
I have a solution which I have a number of unloaded projects. When I build the solution locally the unloaded projects are obviously not built. In Configuration Manager, I can't even select configuration, platform, build and deploy options for the unloaded projects.
Now I have created an Azure Pipeline which also builds the solution. But the unloaded projects are still being built.
How can I exclude building projects in my pipeline?
Now I have created an Azure Pipeline which also builds the solution.
But the unloaded projects are still being built.
Both Azure Devops Pipeline and VS IDE would call msbuild.exe to build. When building a solution using msbuild, it actually is running command msbuild xx.sln /t:build ....
Check the content of xx.sln file (solution file) we can find it defines definitions about the projects within the solution. That's why if you build the solution, all these projects will be built. This is expected behavior when building whole solution. Sample .sln file:
And it's VS IDE's magic to exclude unloaded projects when building whole solution. The IDE will check the unloaded projects and skip them when building whole solution, it has advantage that the unloading project behavior in IDE won't modify your solution file. (It's important for solution under Git version control).
To sum up: It's expected that building solution will build all projects. When we unload the projects in VS, this action won't affect our source solution file or project file. VS will automatically skip the unloaded projects, which is the unique feature of IDE. (Unload is a UI action in VS, it has no effect on .sln/.xxproj file)
To exclude projects to build in Azure Devops:
1.Specify projects to build when building whole solution. (It doesn't change any file, so that it won't affect Version control)
You can check this answer and corresponding document. My devops task setting (no need to specify Build target):
2.Exclude projects from solution configuration (Not recommended) or create a new configuration that excludes specific projects (Recommended). The solution configuration is defined in solution file (sln), so this way would makes effect on Source control.
Exclude projects from solution configuration(Not recommended):
Create a new configuration that excludes specific projects:
Related document here. I suggest you can do the changes via VS IDE, and then push the commits to remote repo. It's complex if you're not familiar with msbuild and sln file, so I doesn't suggest doing that yourself. Let IDE do the job for you.
Once the remote repo get the changes:
We can build the solution in devops with customrelease configuration which excludes ProjectA and ProjectB instead of release configuration which contains all projects.
All these workarounds had been tested on my side before posting them.
Our company is planning to start a large new WinForm project, it will be written in c#-4.0 using Visual Studio 2010.
This project will have many modules (Production, Accounting, Service and etc...) and each module with have lots of possible forms. So we are testing the idea of create multiple projects inside a single solution and have each module be it's own project rather then having a single very large project.
I created a test solution with two projects A and B, next I added each project as a reference to the other project, when adding one project as a reference to the other, I right clicked on Reference>Add Reference>Browsed to the other projects bin/Debug folder and added the other project's .exe as the reference. Next, using the other project as a namespace I was able to do things like form inheritance and opening forms or calling methods between my two test projects.
But I accidently clicked Clean Solution which cleaned the bin/Debug folder for my two projects, and all of my references between the two projects were broken.
What is a proper and reliable way to add permanently references between projects inside a single solution? I was thinking I could physically copy each project's .exe into the other projects bin, then add it as a reference. But that means I'll have to manually re-copy it every time the other project get's updated.
I know that I can define a specific build order using dependencies in Visual Studio, but my question is do those dependencies and build order stay the same whenever I check-in my work to TFS and run a build on the TFS server? I ask because I am having some issues when it comes to having multiple projects in the same solution where project B references project A, and project C references project B, etc.
The solution builds locally just fine because I have set the dependencies such that project B always builds first, but it doesn't seem like this configuration carries over to TFS.
Is this possible to do on the TFS build side?
TF Build will build your projects in the same order, dependency order, that they are built in Visual Studio.
If you reference a project (no reference a projects output but the project) then it will all cascade correctly. Direct Binary references do not cascade correctly as both VS and MSBuild assume it is already built.
Make sure your updated solution file, with the build order, Is committed to TFS.
Ensure that your build is targeting this solution file rather than a list of projects.
As others have said Project References are the key, check all references point to the project and not the binary output.
If the references are correct then the build order will be correct automatically and manual intervention is only really required for projects such as wix projects where the installer project should always be built last after all of the other outputs have been completed.
I have a Visual Studio solution and I want to setup project dependencies in following way:
Project A needs project B during runtime. E.g. when someone Builds project A, project B should also be built (unless it is up-to-date).
Project A does NOT depend on project B in compile-time (e.g. it doesn't statically link to project B etc.). Therefore they can be built in parallel.
If I set in Project Dependencies dialog for Project A that it depends on Project B, Project A will be built only after project B is finished building. Because I have about 100 projects in a solution, this significantly slows down build.
So my question is: can I setup dependencies in the way that Project A requires project B, but they could compile in parallel?
Update
The most common case when we run into problem is when someone just forgets to build the solution before launch. When dependencies are set, VS brings up a prompt to build all projects depending on startup project. When there is no project dependency and project B was modified, VS doesn't issue any message to user, and this usually results in nasty runtime errors.
At the moment we are using following workaround: project A does not have dependency set on project B, and we set Projects and Solutions -> Build and Run -> Only build startup projects and dependencies on run to false (not checked). However, this is a global setting, not a solution option. So I wonder if there is more correct way to solve this problem.
I recently upgraded to VS.NET 2012 and I started encountering a very frustrating issue when debugging.
Project A has a project reference to Project B. When I edit Project B, I would expect that action of building/debugging Project A to detect the change in Project B and automatically include it during the build of Project A. (That's kinda the point of project dependencies.) And that's exactly what used to happen in VS 2010.
But this doesn't happen in 2012. Indeed, even if I build Project B explicitly, Project A will not pick up that change unless I rebuild project A.
So now I'm forced to explicitly build Project B then go back to Project A and explicitly rebuild it for the modifications in Project B to be included.
Thoughts?
Did you set the dependency projects in your solution?
We can set them from:
Right click solution->Properties->Project Dependencies
By the way, did you build your solution in the Visual Studio IDE or by msbuild command?
If you use msbuild to build the projects, you should add DependsOnTargets attribute in your project files.
More information you can refer to:
http://msdn.microsoft.com/en-us/library/ms366724.aspx
Your 3rd paragraph seems to indicate a misunderstanding with the way dependencies work. Forgive me if I am mistaken.
If project A has a dependency on project B, building project B would not force a rebuild of project A. Building project A however should check for changes in project B and rebuild B automatically if needed.
Project A in this case is the parent or root project. Building the parent would check all the projects on which it depends and rebuild them if they are out of date. Always building the parent would automatically build outdated dependencies first, and then the parent project would be built picking up any new changes in the dependencies.
A
\
B
|\
C D
In this example, if B had dependencies they would be built as well. If you explicitly built B, its dependencies C and D would be checked and rebuilt but not A.
If you explicitly built A, first C and D would be checked and rebuilt if necessary, then B, then finally A.
I had a similar problem before, and the cause was that the A's reference to B was a regular reference (to the DLL file), rather than a "Project Reference". This situation would certainly explain the behaviour you see.
To check, look at ProjectA.csproj in a text editor, and examine all the <Reference> and <ProjectReference> elements to make sure they are the way you think they should be.
I think you're looking for a continuous integration (CI) server. A CI can be configured to monitor source repositories and triggered to build target assemblies when new changes have been committed to the code base.
Otherwise, as others have mentioned, project dependencies can be used to rebuild referenced assemblies.
One potential cause of this is locked .suo files. See my answer on this question:
Visual Studio 2012 not building dependent projects