I am working on a web application in VS 2008. To compile the applicaiton I go to Build in Visual Studio and click on Build Solution and when i have to deploy the site I click on Publish and it publishes the site to a directory.
Now my question is when do we use this msbuild file? what exactly this file does for Us?
Thanks.
You use a Build file when you have to do a series of operations that you want to do before or after compiling. This is used in most of the big projects where there will be other things (examples for other things are given below) that needs to be done and through MS build they will automated.
Examples of things that can be done with build :
Running Unit tests
Functional testing
Static Code analysis and reports
Packaging as an installer
Related
I come from a Continuous Integration and Continuous Delivery (CI-CD) implementation project background for java web applications. Now i am working for a .NET based project. Microsoft technologies is completely new to me. It is using the MsBuild for the build process via Jenkins. I am learning MsBuild at this time. The more i read, the more confused i am with the Microsoft way of doing this.
I noticed that the msbuild is executed for every environment where the app is going to be deployed using various configuration and profiles based on the environment for the deployment. Below are some msbuild commands for 2 different environments (PIE & TEST)
C:\\Program Files (x86)\\MSBuild\\12.0\\Bin\\MSBuild.exe" /p:Configuration=PIE /m:4 /nr:false src/myapp.sln
C:\\Program Files (x86)\\MSBuild\\12.0\\Bin\\MSBuild.exe" /p:Configuration=TEST /t:Rebuild /m:2 /p:DeployOnBuild=true /p:PublishProfile=TEST src/myapp.sln
C:\\Program Files (x86)\\MSBuild\\12.0\\Bin\\MSBuild.exe" /p:Configuration=STAGE /t:Rebuild /p:DeployOnBuild=true /p:PublishProfile=STAGE /m:2 SprintA/src/myapp.sln
i may be wrong, but i feel that the code being deployed to the two environments (when the code progress from PIE to TEST) is being build for each environment which is not the real code progression concept. IMHO, the build is done once and its progressed to subsequent environments for testing/validation as long as there are no bugs in the code. The various environment specific settings are handled via config files inside the package and the containers (tomcat for a java app) are started with the parameters that reads/parse the confif files.
Is there a way to handle this in .NET? The app is deployed in IIS
UPDATE:
The more i do research reading various docs and blogs, i came across the web publishing method using msbuild for each configuration and the deploy/publish profiles. IS this just the standard way that the mass follows for a .net project's CICD?
Yes, this is something Microsoft realized and is enforced using the new Release System.
Basically you have a "process" (Build) building your code and producing artifacts (ie. website file structure, nuget package, installers, etc) in this process you typically take care of things like applying the version value to your assemblies, minifiying js and css files or anything not related with the any specific environment.
Then you have another "process" (Release) to configure your artifacts based on the environment where they will be deployed (ie. modifying web.config files from your website) and deploy those artifacts to the desired environment without having to build them again. (ie. push nuget package to some pre-production nuget feed, copy you website structure to the server, etc)
How do you implement these two "processes"?. Well, that depends on your preference and tools. If you use Visual Studio Team Services you have these processes clearly defined out of the box by the infrastructure, and a lot of built in task to support them.
I have not worked with Jenkins but as long as you can use msbuild you could have 2 msbuild projects one to build your artifacts from the source code on different branches and another one to deploy to different environments base on some configurations (ei. your PIE & TEST) and of course you could use tools like powershell or MSbuild custom tasks to support more advanced scenarios within your processes.
I am working with integrating in MSBuild xml tasks file in to a visual studio 2012 solution. The file performs 2 tasks, 1 to validate against StyleCop, the other to run FxCop analysis. I have created the msbuild file from tutorials on the web.
My question is, where should the file be stored on the file system? I presume its outside of the solution. How do I set up the solution to run this msbuid file? I use TFS for source control and TFS Build 2010 for CI so I am looking to integrate it in to this also.
Here is the way that I have our source control tree laid out where I work:
Root
-- Artifacts (Reports folder for build. Items are not checked into TFS)
-- BuildOutput (location where all compiled code is sent. Items are not checked into TFS)
-- BuildScripts
-- ConfigFiles (config files used for different kinds of builds)
-- MSBuild (MSBuild scripts that I have written for our build)
-- MSBuild Extensions (MSBuild extension that I use as part of my build)
-- Database (folder for all database related items)
-- src (folder for all DotNET source code)
-- ThirdParty (folder to hold all of our third party dependencies like NUnit, Specflow, etc)
This has worked out fairly well for us.
Typically, when you want to integrate things like styleCop and FXCop you will include them as steps in your overall build process and not directly into a project or solution. For example, the build process that I manage has 12 different steps that it performs. I do things like 1) compile code, 2) run unit test and code coverage, 3) run integration tests, 4) run duplicate finder, etc. You would want to set up the same kind of thing as part of your build process.
I do not have much experience with TFS Build (I started using TeamCity by JetBrains over TFS Build) but you should be able to modify your build template to integrate your MSBuild scripts into your build process. I also think there are some extensions for TFS Build that allow your to execute StyleCop and FXCop directly within the build template.
Hope this helps.
Any way to replace visual studio's usage of msbuild and still get error reporting in the IDE? I think I might want to compile in VS with NAnt or Rake or PowerShell, or something that is just as smart but uses a scripting language instead of XML. My build is fairly straight forward -- find all the .cs and compile them and put the dll in a Debug/ or Release/ etc.
I'd like to add a number of other steps that just seem easier from the command line:
Like hit the server to prime certain caches.
Compile with Closure
Minify CSS
Generate some metrics after build (in a certain config)
Run NUnit (or custom) testing framework and send an email
etc....
However, I'd still like to get the "error on line" feed back inside of the IDE. Is this a possibility?
You could write some extension for Visual Studio (Macro, AddIn, Package, etc.) that can augment Visual Studio to let other build tools run. The simplest form is probably just using "Tools\External Tools.." and add your Build Tool there. As long as you format your "build messages" as described here, the should show up the output window as if they were generated by MSBuild.
However, I don't think it is possible (nor desirable, BTW) to completely replace MSBuild in Visual Studio.
Visual Studio not just executes MSBuild.exe and parses it's output. The integration is very tight and a lot of GUI aspects rely directly on the content of the MSBuild file.
For example, when you change some project properties in the Visual Studio UI, the changes are (eventually) written to the MSBuild file of the project.
Also, there are some performance improvements, for example Visual Studio "replaces", so to say, the call of csc.exe (the C# compiler) from an MSBuild file by using an in-process compiler, which safes some compile time, because less external processes need to be launched (also described in the above mentioned document)
While all this, from a architectural point of view, is quit likely wrapped and encapsulated by some "interfaces" inside Visual Studio, I haven't yet found a way to have those "interfaces" implement something else that, for example, uses NAnt behind.
Anyway, I think even if technically possible, it would not be technically feasible.
For rake, check out Rake Runner extension. You can run the rake tasks from the solution explorer and check the errors and other output in the Output pane. I have little experience developing vs packages so if anyone want to help, the project is open sourced here.
I am trying to convert a build system setup with TeamCity and Nant scripts to use TFS2010 (We bought the license and might just as well make use of it) After some work I get the web project to build and deploy to the web-server. We have a domain, API, test and web project in our solution.
How do I configure TFS to run the unit tests that we have written so far? I did configure the build to look for ***.UnitTest.dll in(VS2010) Edit build definition>Process>Automated Tests
Now the build fails with a message that says:"Could not load file or assembly 'nunit.framework, Version=2.5.3.9345" Am I correct when I say that TFS is trying to run NUnit on the build server? I did install NUnit-2.5.3.9345 on that TFS2010 build server and still nothing?
Thank you
Jack
The build facility in TFS uses MSTest as test runner, with which it's tightly integrated.
If you want to run your unit tests with NUnit as part of your build, take a look at the NUnit for Team Build project on CodePlex.
The project started out for TFS 2008, however support for TFS 2010 has been added in version 2.0. Note that this feature is still in early stages of development, so your mileage may vary.
I'm late to the game, because I've had to deal with this issue recently. I found this article helpful for me in this. It didn't work right off the bat, but I found if I added it into my buildscript via the controls in a similar manner/pattern, it would work.
My only problem now has been getting it to actually error (right now it warns) even when flagging them to cause the build to error
Link: http://blog.gfader.com/2011/06/running-nunit-tests-in-tfs-2010.html
I seem to have missed Day 1 of MsBuild 101. I find myself asking "What does it do, what does it replace, and when do I need it?" since I can just hit F5 and compile my application.
What is the bigger picture I'm missing?
MSBuild is the build platform that enables all build activity in the Visual Studio world.
A better, more practical example would be to state that
The .csproj files (every C# project) are msbuild files
When you hit F5, you basically (oversimplifying) call msbuild.exe and passing in your .csproj file.
MSBuild empowers all the things that make hitting F5 work. From creating the "debug" or "release" folder, to dropping references into the bin\ directory, to invoking CSC ... and everything in between ... MSBuild "powers" all that.
If all you will ever need from a build is the output that F5 gives you, then you know about all you probably need to know about MSBuild.
In most commercial/practical development scenarios, however, there will come a time where there is a need to customize the build process. The most common approach is automating the build process (using either TeamBuild or some homegrown system). You may also need to
create a "packaged" deployment
link to another library outside of your project that is also actively
being developed
publish your build to an FTP and send an email to a customer notifying
them of its availability.
The use of a unified and extensible build platform (ie MSBuild) is what makes all these these possible, while still being part of the build process ... keeping the "build" part of the development pipeline simple and contained.
It's useful when you want do automated builds, and have to implement a build process
The F5 Key Is Not a Build Process and links therein (e.g this) is a good read in that regard.
Also, your Visual Studio project files are msbuild files. If you want to do more advanced stuff when you build (e.g. run a javascript minifier, have more control over autogenerated version identifiers, post processing of files etc.) , you'll have to dig into msbuild.
msbuild is used when you want to build your project from the command line. Whenever you see a continuous integration product that will automatically build your project, it will call msbuild to perform the actual build step.
I think that build servers should have the option to press F5 key in a simpler way than via windows API.
I know this is pretty stale, but here's my take on MSBuild.
It's a scriptable build tool really similar to ANT. They both use XML for configuration, so you'll be able to figure it out fairly quickly. Both have the concept of "Targets" for instance, lots more similarities in thinking, if you know ANT the switch shouldn't be tough.
MSBuild files generated from Visual Studio is really like the generated ANT scripts you get from Eclipse that build your projects, remember your includes and define your dependencies. You can modify them directly for fun and profit.
I like MSBuild, it fixes some of the stuff I find annoying about ANT.