I'd like to invoke MSBuild to build a single project inside a solution.
Therefore I use
MSBuild MySolution.sln /t:MyProject
Since I have some sophisticated deployment process and I want to save time, I need to build just the one project, but nothing else. Like mentioned here I tried
MSBuild MySolution.sln /t:MyProject /p:BuildProjectReferences=false
which works for project-to-project references, but not for project references defined by the solution (via ProjectSection(ProjectDependencies) in sln-file).
Does anyone know a way to ignore the solution project references also?
Related
I'm facing a weird issue while trying to build using MSBuild.
I'm using MSBuild to build a solution file with /m (parallel build) and BuildProjectReferences set to true.
Suppose I have A.vcxproj and B.vcxproj in the sln file with B having a project reference to A.
What happens is A project starts to build first and while its in the middle of compiling, B project starts to build in another process (since parallel builds) and it would invoke building A.
Now this causes a race condition because we have two processes trying to build the same project A and I would see access issues.
Ideally MSBuild should not invoke building B if A hasnt finished building or if it does invoke B then detect that A is still building and wait for it to finish.
None of this happens. Also, this happens only with MSBuild - doesnt happen if I try to build the solution file from VS2015 IDE.
Any idea why MSBuild behaves this way?
Finally found the solution to my problem
MSBuild expects that the project dependencies be added in two ways
1. In the vcxproj itself, add all the dependent projectreference
2. In the sln file too, define the projectdependencies.
The following VS blog actually states the opposite- For example - https://blogs.msdn.microsoft.com/vcblog/2010/02/16/project-settings-changes-with-vs2010/ states that projectdependencies and projectreference are analogous and use only one specifically projectreferences.
This may be true when you build using VS IDE but not for MSBuild. It needs the project dependencies to be defined on both ProjectReference and ProjectDependencies.
Hope this helps anyone who hit into the same issue as mine.
I am using Windows installer xml and now my project moves to Team Services.
However, my Paths wont work anymore and I need to update my setup.
On the local build machine I used this hardlink: C:\Projects\Solution\Project\bin\Release\Assembly.dll
My Question: What is the best way to build 4 projects and then run a 5th project, which uses the assemblies in the bin/release directory?
Add a reference to the project and then use $(var.Project.TargetPath) instead of the hardlink (or $(var.Project.TargetDir)Assembly.dll). The references will add dependencies on those projects to the wixproj which means they all must be build before the wixproj so all the binaries will exist. All the projects should be included in the same solution as the wixproj.
Here's a resource for all the automatically defined compile time variables you can use http://wixtoolset.org/documentation/manual/v3/votive/votive_project_references.html
Alternatively if you can't do it this way you can define the variables in the <DefineConstants> of the wixproj. It would be something like "ProjectDir=$(MSBuildThisFileDirectory)..\Project\bin\Release\" and then in your wix component where you are using the SourceDir hardlink you would use SourceDir=$(var.ProjectDir)Assembly.dll
All of this stuff is taking advantage of MSBuild. It takes a long time to wrap your head around how MSBuild works but it is definitely worth it if you will be using Visual Studio to build all your projects.
I want to build a project with a particular named Build Configuration, let's call it Conf-A.
This is running as an MSBuild step on TeamCity. When the build runs, it spits out:
The OutputPath property is not set for project ... You may be seeing this message because you are trying to build a project without a solution file, and have specified a non-default Configuration or Platform that doesn't exist for this project.
This project is part of a hulking great solution we load on our dev machines.
The error makes sense for my situation, since I'm building just the proj file, but I don't want to use the solution file since I'm trying break-up this monolithic app.
I want the build-server to treat this project as it's own component, even if for the moment it is part of a solution and has references to other projects (assemblies) in the solution.
Must I build this via a solution file?
I could potentially copy the solution file and prune off all the other projects that are not required, but that's more complexity.
(Maybe the error is a red-herring).
you dont need to build a sln. Its like the error says. You just havent specified a value for the variable OutputPath in your msbuild. You can add it to your files or you can pass it in at the cmd line - msbuild someproj.proj /p:OutputPath=C:\notallovermydrive
I am using NuGet to pull in YUICompressor.NET.MSBuild, which in turn pulls in YUICompressor.NET and EcmaScript.Net.
It also adds references to all three DLLs in my web project.
I can then add the UsingTask reference like this:
<UsingTask TaskName="CssCompressorTask" AssemblyFile="$(SolutionDir)\packages\YUICompressor.NET.MSBuild.2.3.0.0\lib\NET20\Yahoo.Yui.Compressor.Build.MsBuild.dll" />
And then use the task to compress my Javascript/CSS in an AfterBuild target
However, I don't want to have to reference these DLLs in my web project (as they are not actually part of what I ship)... but when I remove the references, then CssCompressorTask can no longer find the other two dependent DLLs (they are in different folders off the /packages folder - it works ok if they are alongside Yahoo.Yui.Compressor.Build.MsBuild.dll)
Believe it or not, I have spent hours trying to get the dependencies to resolve:
First I tried to modify AssemblySearchPaths to include all the other /packages subfolders, as here:
https://github.com/BenPhegan/NuGetAutoTransitiveDependencies
This didn't work, so I tried to create an inline assembly resolver, as here:
MSBuild UsingTask Resolve References
This doesn't work either. At the moment, I am thinking the only choice I have is to get the dependent DLLs alongside the UsingTask dll, one way or another... but this feels like my MSBuild foo is failing me :/
Any ideas much appreciated! Thanks.
I needed my custom task to use the JSON API (NewtonSoft). MSBuild did not load the external dll until I ran gacutil /i [path to dll].
Ok, v2.4.0.0+ now include the DLLs
I am trying to make a build script for a .NET solution which consists of several c# projects and one custom project. The custom project can be build by devenv but msbuild chokes on it.
I would like MSBuild to ignore the custom project because I'm already building it with an Exec task. I actually need MSBuild to not even open the custom .proj file because it's in JSON format and thus causes MSBuild to crash out.
The /BuildProjectReferences=false switch doesn't work. MSBuild still tries to read the custom project file. Is there any way around this?
This question stemmed from a project which had a SilverFrost Fortran project alongside several c# class libraries. The solution would only compile using devenv. Msbuild would throw an error on the Fortran project because it doesn't use the standard .csproj format.
Even with /BuildProjectReferences=false, msbuild would try to read the Fortran project and throw an error. The workaround I discovered was to wrap the msbuild task in an nant task which does the following:
Invokes the Fortran command line compiler
Removes all references to the Fortran project from other .csproj projects using the xmlpoke task
Replaces said references with a direct dll reference to the Fortran compiler output
Invokes Msbuild on the modified solution
Instead of building your solution once by MSBuild, try to build each project one by one. In this case, you can ignore the desired project. You can also define your own "Exec"-based build in this new script.
In your project that uses the custom project, can you right click on the Project Dependencies and remove the custom project from the list? You can refer to the custom project's binary output instead.