I'm a solo developer running Visual Studio 2008 and looking into MSBuild to improve my build process.
Almost all of the tutorials I've found so far have plenty of information about writing a build file. However I'm having a lot of trouble finding out how to integrate MSBuild into Visual Studio. Maybe MSBuild is only used with something like CruiseControl but that's overkill for me as a single developer.
Where should the build file live in a Visual Studio project and how can I run it from within the IDE?
Visual Studio executes MSBuild automatically for projects it supports.
If you right click on a project and unload it, you can then edit it in Visual Studio. Reload (right click on project again), force a (re)build to test your changes. An alternative is to edit the project file in an external editor and Visual Studio will detect saves and offer to reload the project for you.
Sounds like you're on the right track, and if you are considering writing Targets or custom MSBuild Tasks, take the time to separate them from your current project so that you can re-use them. Don't re-invent the wheel though, the two main complementary MSBuild projects are MSBuild Community Tasks and MSBuild Extension Pack.
Update: Judging from your comment on Mitch's answer, you might also want to consider adding a new Configuration element or custom properties to a project. A new MSBuild Configuration (something other than the default Debug/Release) could run unit tests, build documentation, or whatever you want automated. A custom MSBuild property would allow you to use normal Debug/Release Configuration and extend it to automate more of your build process, just depends on what you want. Either approach could also be driven from the command line.
As others have noted, MSBuild is already available when you install Visual Studio.
If you want to integrate into VS2008: Running MSBuild from Visual Studio
MSBuild is the build engine used by Visual Studio to process the files included in a project.The Visual Studio project files themselves (**.csproj* for C#, and .vbproj for VB, for example) are in fact MSBuild scripts that are run every time you build a project.
Your .csproj file is a MSBuild file. So you are actually using it already.
You may of course wish to create a separate build file to have more control, especially within a continuous integration or nightly build say.
If you simply wish to edit your project build file then you can use the IDE to edit some settings such as pre and post build actions or edit the Xml itself by unloading project and right click and editing.
You can use your current .vcproj files to build your project with MSBuild. However, as MSBuild is not directly supported (at least for vc++) vcbuild is used instead (internally).
In VS2010 all project files are MSBuild based...
This is an older article about some simple extension points from the msbuild team
How To: Insert Custom Process at Specific Points During Build
Also, don't forget you can use the MSBuild SideKick for developing and debugging your (local) msbuilds, available for free at http://www.attrice.info/msbuild/
I'd suggest you call msbuild as a post build step. Then you can put your build script somewhere in your solution and call it.
<windowsdir>\Microsoft.NET\Framework\v3.5\MSBuild.exe c:\temp\MyProject\mybuildfile.proj
The easiest way is probably to invoke your custom build script using a post-build step. Right click project, choose "Build Events" and call msbuild with your custom msbuild file from there.
I use the msbuild template to intergrate with visual studio
http://msbuildtemplate.codeplex.com/
Related
Developers use the Visual Studio (VS) GUI to develop their solutions and get their projects all building using a solution file (.SLN). The build teams using vNext then have to automate those builds using MSBuild instead of devenv.exe (the Visual Studio executable file). This is a serious and chronic problem because not only is MSBuild incapable of building several project types, but the build order is defined in a completely different, and complex, way.
Some Microsoft advice (https://learn.microsoft.com/en-us/archive/blogs/msbuild/incorrect-solution-build-ordering-when-using-msbuild-exe) is to switch to explicit dependencies in each .*proj file and remove all dependency specifications in the .SLN file. This sounds like a person who has never worked in a relatively powerless build team trying to get development teams to:
do a lot of what they perceive as time-wasting extra work and to
change how they do things
What build teams need is a way to automate whatever VS allows dev teams to build. If VS is given a SLN to build, then a vNext build needs to be able to use that same SLN in the same way. Instead vNext currently only offers MSBuild as the build tool. MSBuild has many more options than devenv, so that would be great, IF it could be made to use the SLN to govern dependencies in the same way as VS, and would be upgraded to build all the same project types.
There have been prospective efforts, referenced by PatrickLu-MSFT at Build project using devenv.exe in TFS 15RC1 Build Server, to enhance a vNext build step to allow devenv to be used instead of MSBuild, but those efforts seem to have been dropped.
Maybe someone has developed a custom vNext build step to build using devenv?
Here is an existing extension you can reference, which provides a build task in your TFS/VSTS instance that will allow you to build your projects using DevEnv.com (Visual Studio):
https://marketplace.visualstudio.com/items?itemName=mmajcica.devenv-build
If you want to automatically use TFS/DevOps build whatever solution files our development teams get working using Visual Studio, you could set CI trigger in build pipeline, when the solution build successfully on local, you can check in/commit the changes, and trigger TFS/DevOps builds.
I'm contributing to a fairly large project that uses MSBuild properties to control the build process. I am running some tests from the command line like this:
msbuild /p:Configuration=Release /p:OSGroup=Windows_NT /p:Performance=true
And everything is working fine. However, when I try to run the tests from Visual Studio, the OSGroup and Performance properties are not set, which causes things to not work correctly.
Any idea how I can set these properties before building my .csproj file within Visual Studio? It has to be without editing the .csproj file, since I don't to accidentally check in any changes I make there. Thanks in advance.
You could just add an external tool command which builds using the same command as shown. VS will parse the output just like from it's own builds, so warnings and errors are shown in the Error List etc. Your command would be something like
msbuild $(SolutionDir)$(SolutionFileName) /p:Configuration=Release /p:OSGroup=Windows_NT /p:Performance=true
You can implement a Visual Studio extension and access project properties trough DTE.Solution.Projects and Project.Properties. There is an example here:
https://msdn.microsoft.com/en-us/library/bb166172.aspx
VS DTE interface can also be used in a standalone application or Powershell script.
For example, I use Visual Studio to create a mono game project in the solution, and I add another wix project that
when I hit "build solution", the mono game project being build, and wix project build a installer directly afterward.
In this way, I don't need to separate my project everywhere, because I just want some more additional options with One-Click installer.
If I can use Wix, I can customize the installer, but how?
After search for some time, I found this
http://wixtoolset.org/documentation/manual/v3/votive/votive_project_references.html
But, I would like to put two projects in a same solution folder, rather than two separate solution folder. This way, if I change the path, will the link just broke up?
Yes, you can. Simply add a reference to the project from your WIX project.
Note that with project references, you can use variables in your wxs files. For example if your game project were DavidWong.MyGame:
<File Id="MyGame.exe"
Name="$(var.DavidWong.MyGame.TargetFileName)"
Source="$(var.DavidWong.MyGame.TargetPath)" KeyPath="yes" />
See the documentation for more info.
Yes, it can be done ( project reference and $(var.ProjectName.TargetDir) and so on ) but in my experience there are a few reasons not to:
1) When a new version of Visual Studio comes out you might be stuck if a new version of WiX is not yet released to support that version of Visual Studio. I've seen this several times and currently you'd have to run a beta build of WiX v3.10 if you wanted to support Visual Studio 2015.
2) All developers now have to install WiX or get error messages that some projects couldn't be loaded.
3) Some developers will complain that they don't want "setup" code in their .NET solution. I think this is a thin complaint but I kinda get it.
What I like to do is have an application solution and an installer solution. I use postbuild copy commands and MSBuild publish profiles to stage content in a "deploy" folder that models the deployed system and then use that reference that structure in my wix code.
I am currently trying to set up a automated publish using MSBuild and am now realizing that it produces a different output when doing it from MSBuild instead of Visual Studio. I am not sure what I am missing here, but for some reason it is copying different project files into the route web project directory.
Is there a way to simulate a Visual Studio Publish using MSBuild? I am currently doing this with an Orchard Project, figured that would be worth mentioning.
Here is the command I am currently using to do this:
/p:PublishProfile="exampleprofile";DeployOnBuild=true;VisualStudioVersion=12.0;
FrameworkPathOverride="C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\v4.5";
PublishProfileRootFolder=%WORKSPACE%\src\Orchard.Web\Properties\PublishProfiles;
Password=ExamplePass;Configuration=Release
As far as I can understand, you're trying to simulate a ClickOnce publish using a manual msbuild routine. You can achieve that by calling msbuild with the correct parameters. To simulate the ClickOnce, the target publish is available for you.
msbuild MyProj.csproj /t:Publish
Given your specifications, you have to be able to run multiple publish configurations, each one having its own output settings. To be able to run multiple profiles, I would recommend that you abandon the PublishProfile attribute (I never understood how to get it to work) and switch to the BuildEnvironment as showed here :
https://wallism.wordpress.com/2009/12/21/msbuild-and-multiple-environments/
(Focus on the "Setting up the customizations" part)
You have to adapt your call to msbuild to include your build environment
msbuild MyProj.csproj /t:Publish /p:BuildEnvironment=MyConfig
Just for a little test, for you to know if this is useful, follow the tutorial, create your target, and add a
<PropertyGroup>
<PublishUrl> Add a custom path here </PublishUrl>
<InstallUrl> Add the same path here </InstallUrl>
</PropertyGroup>
to your target file.
Run then the msbuild and let me know if you solved your problem
I've got a Visual Studio 2010 solution that I would like to add a project to that only contains some command-line scripts. This project isn't meant to actually compile/build anything, but I want to be able to edit my scripts with the rest of the solution, and have TFS integration etc.
Unfortunately, in searching I get a lot of results for errors where builds don't happen, or other conditions where specific build targets are implemented. I simply want a non-build project in VS as a visual repository for the editor. I don't want to one-by-one include individual files in a solution folder.
In the build configuration manager (On the Menu, "Build", "Configuration Manager"), there is a "build" checkbox for each project. Uncheck it for your script project.
Could you make a content project, add your scripts to it, then change their properties to "Do not compile"?