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
Related
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.
I want to build a .vcxproj via MSBuild from outside Visual Studio. The problem is that there are many occurrences of $(SolutionDir) inside the .vcxproj file which apparently only get set correctly when the solution is loaded.
When I replace $(SolutionDir) with the actual absolute path, it works. But other people on other machines are working with the same project file, so this is not a solution.
Is there a solution or hack to solve this problem?
You can set the variable by passing parameter arguments:
/p:SolutionDir=path
So, rather than editing the solution file, you can create a build script that sets up the environment and executes MSBuild accordingly, leaving the Visual Studio file as is for development work.
You can use a relative path.
I am not sure about Visual Studio 2010 as in the question, but it guaranteed works since Visual Studio 2012.
If the project folder is right under the solution folder then the relative path is ..\\.
This, by the way, can be combined with the parameter argument from Grant Thomas's answer.
<SolutionDir Condition="$(SolutionDir) == '' Or $(SolutionDir) == '*Undefined*'">..\</SolutionDir>
The solution to explicitly pass SolutionDir as an argument is insufficient for me.
Namely, if the project I want to build has dependencies with different build configurations, the build fails with a This project doesn't contain the Configuration and Platform combination of <my target configuration> error.
This makes sense, since I didn't specify the target configuration for the dependencies and thus it tries to target same configuration as the project I'm building, which they don't have (in my case).
Since a solution file contains the build configurations for all projects in the solution (given some solution-configuration), we want to make use of this solution to solve this problem. Luckily, MSBuild allows us to build a solution and pass a specific target project as argument, which will only cause that project to be build (together with its dependencies).
msbuild MySolution.sln /t:MyProject
In the project I've inherited, the original developer used a number of post-build events in his Visual Studio projects to copy around DLL's and stuff when building inside VS.
This is causing some grief now that I'm trying to move these things to the TFS 2010 Build system.
I was hoping to be able to create a new "Continuous" project configuration, and exclude those post-build events from Visual Studio in that configuration - but it seems those calls aren't configurable based on your project configuration....
Any ideas? Is there something I could check for to know I'm running under TFS Build and then just skip those CMD files? Any ideas would be most welcome!
My approach is to guard the pre- or post-build code with this
IF "$(BuildingInsideVisualStudio)"=="true" (
…your code here…
)
That variable is automatically defined by Visual Studio and you do not need to change the build definition.
I use a similar approach to do this. I add the following to each project's post-build steps:
if '$(TeamBuild)'=='True' exit 0
Then when configuring the Build Definition I simply add:
/p:TeamBuild=True
...to the MSBuild Arguments.
This gives me the flexibility to keep all the configuration in the projects and the build definition.
What if you set an environment variable on your team build server, and then you could write a check into your post build steps to check for that environment variable. If the environment variable is set, you'd know to skip the command files that do the post build steps because you'd know you are running under TFS build.
You could combine all your post build steps into one script possibly, and then just check the environment variable at the beginning of that script.
Or you may be able to do it the opposite way and build the check into your TFS build script. You can refer here for how to check an environment variable in a TFS build.
So in your TFS build script you'd have something like:
<RunScripts Condition=" '$(RunScriptsServerVar)' != '' ">
the environment var is NOT set, so run your scripts since we aren't in
a TFS build
</RunScripts>
Allow me to start by saying that this is a new and first time TFS deployment with 0 experience in Visual Studio as an added bonus. I've managed to get everything installed and am excited to say that I can even deploy as part of the build process to our different staging environments, but this is where things have gone south.
I'm trying to set up separate build definitions for each stage of development so that I can take advantage of config transforms and use granular permissions for who gets to promote where. In the configuration manager I have it set up so each solution configuration has a 1-1 mapping to a project context and always building 'Any CPU'. The problem is that when I use the /p:Configuration=QA switch in the MSBuild Arguments or just specify it in the 'Items to Build; section of the Build process parameters the build fails with a warning and it doesn't seem to get as far as MSDeploy.
Using the following arguments to MSBuild I am deploying with a default configuration, but again, no love on specifying a configuration.
/p:DeployOnBuild=True /p:DeployTarget=MSDeployPublish /p:MSDeployPublishMethod=WMSVC /p:MsDeployServiceUrl=10.31.60.109 /p:username=tfsdeploy /p:password=lulz /p:DeployIISAppPath=Bob /p:AllowUntrustedCertificate=True
Here is the warning I get in the TFS Build Explorer when specifying the configuration to use.
C:\Builds\2\Bob\Bob - Final Test\Sources\Bob\Bob.sln.metaproj: The specified solution configuration "QA|Any CPU" is invalid. Please specify a valid solution configuration using the Configuration and Platform properties (e.g. MSBuild.exe Solution.sln /p:Configuration=Debug /p:Platform="Any CPU") or leave those properties blank to use the default solution configuration.
The solution originally was created in VS2008 and a local copy from VSS was pulled down with VS2008 and then pushed into TFS2010 using VS2010 pretty much letting MS work its magic to convert/update.
Any help is greatly appreciated.
The issue I ran into here was that the names of the build configurations were different in the .sln and .csproj files and these can't be mapped to each other as I thought I was doing from within the VS2010 ide.
This is actually a pretty simple error. If you get it, check your spelling in the build definition then verify against the .sln and .csproj files using a text editor like vim/notepad.
Did you get this fixed? I've noticed some of our builds are "AnyCPU" and others are "Any CPU", makes reports a little more interesting!
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/