I have a Visual studio solution with multiple projects
Let say project Core, CoreExtended, ProjectA and ProjectB.
-- CoreExtended has as dependency Core.
-- Project A and ProjectB have as dependencies CoreExtended an also Core.
When i try to Build with multiple threads, msbuild has a problem because both projects ProjectA an ProjectB try to get Core and it fails. I have revised all dependencies and order. Why Visual Studio does not protect this and compile first ProjectA and then ProjectB?
Why other projects than only have Core as a dependency don't fail?
Obviously when I put only one thread when building it work right.
Thanks in advance.
Sometime ago we had some similar problems. It turned out that some of the projects had the same output directory which caused concurrency problems.
Related
Suppose I am building two class libraries in a single solution in visual stuido. The projects are called "Core" and "Extensions".
Extensions depends upon Core.
I would like to publish these as separate nuget packages for other developers to consume, because while the Core package would always be used, the extensions package just provides some optional functionality.
When I am developing the solution in visual studio, however, it is much simpler for me to set a project dependency from Extension to Core. Otherwise (in a naive approach), building the whole solution would require the following steps:
In visual studio, commit and push Core.
Wait for the CI server to build Core and publish the nuget package to our internal feed.
In visual studio, manage nuget packages for the Extensions project.
Connect to the internal nuget feed
Get the updated Core nuget package.
This approach would work, but is obviously very tedious.
The main difficulty I have been encountering while researching how to do this is that the way all of these things interact has been changing quite rapidly over the past few years, with sdk vs non sdk style projects, nuget pack vs dotnet pack vs msbuild pack, and so on and so forth.
Perhaps the most relevant, most recent answer appears in this question How do I create an individual nuget package for each project in a solution, with project references converted to nuget dependencies? however the answer is now quite old, and is for a dot net framework style project (using packages.config), not a .net5 project.
So, can anyone provide up to date advice on how to correctly accomplish the following:
In a visual studio solution with multiple .net5 class library projects, have dependencies set up as project dependencies at dev-time, but convert each project to its own nuget package with the equivalent package dependencies at publish time.
We have a Vb.net project which is using C1.WPF.4.dll assembly.
When we create an installer project C1.WPF.4.dll dependency gets added to the project and installer.
We tried to exclude C1.WPF.4.dll from the main project.
Tried to remove the reference from dependency and VDPROJ file
C1.WPF.4.dll has dependencies of .net framework.
all other dlls can be excluded but only this dll is unable to exclude.
But if we rebuild the project the dll still appears in the installer project.
How can we exclude or remove dll from the installer project?
thanks in advance.
We are using Visual Studio 2017 to create the installer.
https://i.stack.imgur.com/B3HLA.png
This is one of the many reasons I don't recommend using Visual Studio Deployment Projects (.VDPROJ). I spent years trying to turn off this automated dependency scanning. It's impossible really.
Check out Windows Installer XML (WiX - opensource) and Industrial Strength Windows Installer XML (IsWiX - opensource by me). I have a tutorial here:
https://github.com/iswix-llc/iswix-tutorials
MSDN docs Visual Studio Integration (MSBuild) state:
Building Solutions
Within Visual Studio, the solution file and project build ordering are
controlled by Visual Studio itself. When building a solution with
msbuild.exe on the command line, MSBuild parses the solution file and
orders the project builds. In both cases the projects are built
individually in dependency order, and project to project references
are not traversed. In contrast, when individual projects are built
with msbuild.exe, project to project references are traversed.
With my Visual Studio 2010, when building a .sln file with MSBuild from the command line, project to project references are all built, regardless whether they occur in the solution.
What did I miss here? Or are the docs plain wrong?
You are correct that msbuild.exe will sort out all project references whether or not they are part of the solution in contrast to building within Visual Studio 2010/2012/2013/2015 (and possibly later versions) where you will get a build failure if a referenced project is not part of the solution or built beforehand.
In short, yes, the documentation seems a bit off.
You can ignore the build of project to project reference by running msbuild Solution.sln /t:ProjectName /p:BuildProjectReferences=false this explain the sentence in msdn.
Is it possible to tell VS not to recompile some projects every time and use already compiled dll-s instead?
You can exclude any project from building in Configuration manager. Just unselect desired projects in Build column. You still will be able to debug those projects.
Instead of project references, you can add the compiled DLLs as references.
Any such referenced project will not rebuild if not changed.
However, since the references will now be to DLLs, you need some strategy to keep them synchronized and up to date with your code.
As I understood your question, you have a solution with multiple projects and you seem to have dependency of some of them on some other.
VS will always compile all the "loaded" projects. But when you add a reference to a project, add it directly to a (preferred) DLL assembly file, and not to one of the projects. This way the other project will be compiled but you are referencing the same DLL assembly over and over. Since if you reference the project, the output of the project is always what you reference actually.
I'm in the process of upgrading our VS 2008 solution to run on VS 2010
I managed to successfully build in VS 2010
My next step now is to configure a build machine running TFS 2008
Whenever I start a build it does my projects in alphabetical order with no regard for dependencies. I've googled a lot and I can't seem to find a solution to this.
The closest solution to my problem is found here: msdn link which links to this: dependency solution
However I'm dealing with 129 projects, so I would really rather not do this all manually in the xml.
Has anyone been able to effectively remap the dependencies in a way which msbuild recognizes without manipulating the xml for days...?
It turns out that the conversion to VS 2010 makes the build agent have to use the .NET 4.0 version of msbuild.
So I followed the steps outlined here and it worked: Building .NET 4.0 Applications Using Team Build 2008. Keep in mind that those instructions were written during the beta and the path is now v4.0.30319.
This was required even though all my projects are targeting 3.5
Basically I had to make a one line change and now everything is happy (still working on getting my build to pass but the order is good). It had nothing to do with dependencies not being preserved, simply that the way dependencies were being managed wasn't understood by msbuild 3.5
We also have a large number of projects. We wound up (programmatically) creating a MasterSolution.sln file that contained all of the projects. We also require our developers to only use project references in their code. This way, MSBuild always gets the correct order as it parses the .sln file.