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.
Related
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?
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
Summary:
Projects build in wrong order with visual studio and managed C++ and C# projects
Description:
I have a massive (100+ projects) solution file that is building a few projects in the wrong order. The solution file contains the following types of projects:
native C/C++
Managed C++
Managed C#
The solution contains all the proper dependencies between the different types of projects. Ok, so when I build from the command line (Using MSBuild), there is a problem. The dependencies for the managed projects (both C++ and C#) get built in the wrong order. For instance a project will fail to build because a managed dependency is missing. For instance a managed C++ file will have a using declaration that will fail:
#using <foo.dll>
since foo.dll doesn't exist yet.
Which means that foo.dll should have been built before, but wasn't.
Like I mentioned earlier, the dependencies are properly set up in the solution file. For instance, if foo depends on baz, I have this in the solution file...
Project("{C4ABA494-43D0-400A-9917-20E167A12CFD}") = "Foo", "...\Foo.vcxproj", "{5A42640E-9E0A-442B-8A40-AA91AD5444AC}"
ProjectSection(ProjectDependencies) = postProject
...
{2CE32AE0-B129-40BA-B06E-A628FA149AB3} = {2CE32AE0-B129-40BA-B06E-A628FA149AB3}
EndProjectSection
EndProject
...
Project("{C4ABA494-43D0-400A-9917-20E167A12CFD}") = "baz", "...\baz.csproj", "{2CE32AE0-B129-40BA-B06E-A628FA149AB3}"
ProjectSection(ProjectDependencies) = postProject
...
EndProjectSection
EndProject
So the solution file correctly has the dependency. But the dependency in the Foo.vcxproj project is only expressed by the #using directive.
I've read on the visual studio blog that there is a known bug in ordering projects in msbuild.
http://blogs.msdn.com/b/visualstudio/archive/2010/12/21/incorrect-solution-build-ordering-when-using-msbuild-exe.aspx
Their work around is to add an item called to my projects, like this:
<ProjectReference Include="... foo.csproj">
<ReferenceOutputAssembly>false</ReferenceOutputAssembly>
</ProjectReference>
Anyways, my question is: do I need to do this ONLY for my managed C++ projects? Or do I do this for Managed C++ AND C# projects?
(I kind of believe I don't need to do this for C# projects since their dependencies are explicit)
Note: I have tried putting this on ALL projects in my build, and it didn't work so hot, as I got lots of strange build errors in my native projects...
Thanks for any response to this.
I had the same issue, but with C# projects only.
It seems like MsBuild is NOT using solution file dependencies. It is using project references inside the project files to create build order. Try to update all your ProjectReferences to get correct build order. In your case you have to add managed project reference (dependency) into your C++ project file.
The answer to your question is: Yes, you have to do it for both Managed C++ AND C# projects. Setting dependencies inside sln file is not enough if you are building with MSBuild.
I know that msbuild does not support VDPROJ files, but it maybe built using command line devenv.
I want to build all prjects (C#) using msbuild task and only after that starting specific setup project from my solution. Of course this projects has dependencies to previously created C# projects (otput from proj1, proj2, proj3).
How could I do it?
Override AfterCompile (or AfterBuild) task and add Exec command for devenv.exe to compile vdproj files. When you run devenv.exe /build /project you will only build the specified project within the specified solution. Only project files that have changed since the last build will be build. Therefore the dependant projects will not be build unless they have been changed.
I have written an MSBuild task that makes use of third-party assemblies.
When I use the task in my project, MSBuild complains that it can't load the third-party assemblies (not surprisingly).
Where should I place the third-party assemblies so that they are available to MSBuild. I tried adding project references to them without success.
I'm not sure if I expressed my problem very well, but now I've found the solution.
In my .proj file, I reference my custom task with the following syntax...
<UsingTask AssemblyFile="..\lib\MyCompany.MSBuild\MyCompany.MSBuild.dll" TaskName="CreateDatabase" />
My CreateDatabase task relies on various 3rd-party assemblies. However, some of these are only referenced via reflection, so weren't included by default in the folder "..\lib\MyCompany.MSBuild".
I had been trying to get the task to work by placing the required assemblies in the same directory as the .proj file invoking the task.
However, what I should have been doing was putting the assemblies in the referenced task directory "..\lib\MyCompany.MSBuild\".
Simple!
You could add them to the GAC (Global Assemby Cache). This only works if it is strongly named.
You could also make sure that you have marked them with copy local = true when you added the reference in the project.