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.
Related
My Visual Studio 2019 solution contains several projects, some of which I don't want to be built as part of continuous integration. Specifically, I'm trying to exclude tooling and unit tests.
In Visual Studio, I have created a new solution configuration and unchecked the "Build" box for each project I don't want to be built.
In TeamCity, I have specified the name of the new solution configuration to use. However, TeamCity continues to attempt to build all projects within the solution.
[I had included screenshots of my solution configuration, TeamCity build configuration, and resulting TeamCity log but I do not have enough reputation to post images apparently.]
From everything I could find so far, unchecking "Build" from the solution configuration used by TeamCity is supposed to exclude that project from building.
I figured it out by finally noticing that the TeamCity log was showing the build configuration as "ReleaseCI|Mixed Platforms" instead of "ReleaseCI|Any CPU". On other projects, I only needed to specify the configuration. For this project, I apparently have to specify the platform as well.
I'm experimenting with Prism, and I've run into a number of inconveniences caused by the fact that the Shell project does not directly reference the Module projects. The primary inconvenience is that the modules output assembly and it's dependencies are not copied to the shell projects output folder after compilation. I've been successful in using xcopy as a post-build event to copy the target assembly to the projects output folder (which is not particularly nice, but seems to work), but not the dependencies.
Is there a standard way to solve this, or is it mostly ad-hoc solutions? Having to set a post-build event for every configuration in every module seems excessive, so I'd like to avoid it if possible.
There is a simple solution for this. You can set up project dependencies in Visual Studio without creating cross-references in the assemblies.
Open the solution properties and go to the Project Dependencies page. Here, select in the combo box Projects your main EXE that contains your shell. Alternatively, right click your main project in the Solution Explorer and select Project Dependencies... there:
In the Depends on listbox, check mark all your module projects that need to be compiled / copied in the output directory.
You can configure further dependencies for all your projects in the solution (e.g. if you have indirect dependencies between modules).
On changing any project that has dependencies, all dependent project will be rebuilt by Visual Studio and processed according the build configuration (e.g. copied to the output directory).
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.
Sorry about the newbie question but I could not find an answer anywhere: I have a Visual Studio 2010 project (C#) with several dependencies on other projects in the same solution. When I debug the project and try to step into code in one of the dependencies, it steps over instead. Also, it seems that it is using a previous, installed version of the dependency instead of using the one in the solution.
How can I make it use the one in the solution and allow step-into?
Figured it out.
The dependencies' compiled versions were installed in the GAC - needed to take them out first.
Needed to turn on Tools->Options->Debugging->General->Enable Just My Code.
Needed to set Copy Local to True for each dependency in the target project.
Like everyone here pointed out, needed to re-build all dependencies first, in Debug mode.
Thanks everyone for your help!
When you add the projects as references, add them using the "projects" tab (of the "add references" dialog) instead of adding them as binary DLLs.
A project's output is only copied to the referencing project's bin folder if the dependent project is build. If the project is used in more than one solution, it may have been compiled previously but it won't update projects in the open solution. If the source is unchanged relative to the binary files, then the project is not compiled and the bin folder is not updated. Use Rebuild or Clean after opening the solution to ensure the projects are in sync.
Also check in Configuration Manager that all the projects have a Build checked.
I have 3 .net projects.
Project1.dll is generated by a VS2008 project.
Project2.dll is generated by a VS2005 project that references Project1.dll.
Project3.dll is generated by a VS2008 project that references both Project1.dll and Project2.dll.
Right now, I build Project1.dll, and manually copy it to the place where Project 2 can pick it up.
Then I build Project2.dll and manually copy it and Project1.dll to the place where Project 3 can pick them up.
Obviously I'm doing something wrong (manual). What is the correct way to keep my projects' references up to date?
Updating Project2 to VS2008 and then creating one solution containing all 3 projects is not an option at this time. We have a 3rd party visualstudio plugin that does not yet work in VS2008. Project2 must stay in VS2005
De-updating Project1 and Project3 to VS2005 and then creating one solution is not an option either. We're relying on C# 3.0 and .net 3.5 features in those projects.
Probably the best option would be to have a common build folder for all three projects. This can be done in the Project Properties-> Build -> Output path. Then point the references to the output folder. That way anytime you build any of the lower projects, the higher projects would have the latest versions. You can set the path per configurations (Debug, Release) as well, so you won't need to change that for each type of build.
How about a pre-build event for Project3, that goes out and uses a batch file to build Project1 copy it to Project2 folder and then build project2 and copy it to project3 folder.
I would recommend sharing the csproj/vbproj files between the solutions. The format of the project files is compatible between the two versions of studio (solution files are not, however), and as long as your VS2008 projects are targeting the 2.0 runtime you should have no trouble compiling them. This will allow you to reference the projects, which will take care of dependencies.
The only place where this gets hairy is if you have a web project that needs to work between the two versions of studio. In that case there are some modifications to the project files which will point to the correct MSBuild target files.
We use a build script that handles the dependencies, builds the DLLs and does what you're doing manually.
A trick I have used in the past is to move everything to 2008. Then I setup a special solution in 2005 for project two and use it to work with the addin. Getting this to work just depends on how bad project two behaves in 2008.