i have a question about Post-Builds. We have a Post-Build in project settings. This Post-Build task compress JavaScript because of Web Application performance. Assembly path is assigned by variable $(YUICompressorDLLPath).
Generally it works fine from developer machine but how should I do it from TFS Team Build. When I start the Team Build it ends with error because the assembly is on the build machine on other place as on developer machine. I tried overwrite the variable over MSBuild Arguments but it seems it doesn't work.
What is the best practice, how is to accomplish this?
Regards
Anton Kalcik
It seems that you should change $(YUICompressorDLLPath) $(OutDir)\$(TargetFileName)
The best practice, on my opinion is to keep the directory structure on build server same as on developer machine. On this way is working everything fine, because of relative paths. For more information to see how to ensure generated file will be deployed see also: Deploy generated files in TFS Build Server
Related
I'm setting up a CI with TeamCity 8 (v8.1.4).
I finally managed to setup TFS integration - ie checkout from TFS.
I used the super easy Auto Detect Build Steps [thank you JetBrains for that] to determine the Build Steps necessary.
I used the Get missing NuGet packages step, which works as expected.
Then I have a Visual Studio Solution build step, that seems to build great, just until the point where it wants to build the Unit Test and Integration Test projects, which both use Microsoft Fakes.
Here I can see that TeamCity tries to search everywhere for the [AssemblyNameUnderTest].Fakes.dll - where [AssemblyNameUnderTest] is whatever dll that is tested.
I haven't included that dll to my project nor in TFS, since I thought that it would be regenerated each and every time I change something to the original AssemblyNameUnderTest (ClassLibrary) Project.
Should I include the [AssemblyNameUnderTest].Fakes.dlls to the project and TFS or am I right that they are regenerated ?
And if I'm right with the regeneration, then why TeamCity can't find it ?
Thanks in advance,
Michael
Ah, so I found the answer to one of my questions: http://hamidshahid.blogspot.be/2012/11/microsoft-fakes-framework.html
The files in the "Fakes" folder are only generated at the time of
adding the fakes assembly. They are added to the solution and should
be checked into source control.
The "FakesAssemblies" folder and all the files in it are generated
whenever the project is compiled. This is important because if you are
adding fakes for assembly for a changing component, the generation of
FakesAssemblies will ensure that all changes are reflected in the
generated assembly.
So I did that - ie it is the default behaviour.
Above that my .fakes files have the "Fakes" build action, but it still isn't working for TeamCity.
Also, TeamCity uses the MSBuild.EXE from "C:\Program Files (x86)\MSBuild\12.0\Bin" for the build.
Anyone a bright idea ?
To fix the build, I removed the Fakes stuff and implemented Moq mocks.
Seems to give you more control of what exactly happens.
Is there a built in way of executing an MSBuild target on the remote server using MSDeploy?
If I include a targets file in my project so that it is deployed is there a built in way or executing msbuild.exe? I know I could use runCommand but then the path to msbuild.exe could be wrong.
I've never heard of a built-in way to execute MsBuild from webdeploy. I don't even think it's necessarily a valid idea to have such a built-in way as target machine can have several versions of msbuild co-existing (v2.0\3.5\4.5\etc) - how do you tell msDeploy which to use?
I suggest, that you use runCommand and refer to msBuild using system variables: %WinDir%\Microsoft.Net\Framework\v4.0.30319\
Keeping in mind that framework versions move rather slowly you're safe (as you generally know, which version of the framework you target)
UPD: if you want a better way to find msbuild location - check out this answer (read from registry)
Referring to the answer on
Exec Task in MSBuild for execution of command on remote machine
MSBuild has no built in support for remote machine installation and only executes commands you tell it too and carries on from there.
In our place we have service installed on the remote machine which keeps monitoring our release folder. As soon as a new item (A zipped item containing all the files) becomes available it will perform our release operation. This might be similar in your scenario too.
My company uses TFS 2010 to deploy our web apps from our local environment to our development environment. Here's the compiled output in my local directory for one of our vended web apps, ProGet, (http://inedo.com/proget/overview) in question that isn't deploying correctly. I expect all of what I see below to deploy to our development server:
Here's my .xaml build file:
Finally, here's my solution in Visual Studio:
When I queue the build, this is what's built out to our development server - notice it's missing a bunch of files/folders, but it does include "Resources" and "bin" and web.config:
This app is a vended application, ProGet, an already developed corporate Nuget repository that we purchased a source code license for. Does anyone have any ideas what I might be doing wrong?
EDIT
Here's a screenshot of my local IIS and the window to the right is a result of right clicking the website and choosing "Explore". Notice the *.cs files. Weird they don't compile down.
The Default Build Template (DefaultTemplate.xaml) should output the same files you get when you compile locally.
However, from your screenshots it looks like you are using a custom build template xxxx_DeploymentProcess.xaml that is obviously doing something different with how it outputs the build files. There is no way for us (stackoverflow community) to know what your custom build process is doing.
You could try switching back to the default template, and we'd be able to help you then. But, there's a good chance that you are using a custom build template for a reason, and you might not want to eliminate it before you know what it's doing.
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.
I've noticed projects such as Msbuild Extension Pack and MsBuild Community Tasks give msbuild the power to install assemblies, sql, and setup IIS. These features seem to be oriented to doing installs and not builds.
So I was wondering how many people out there are using msbuild, perhaps in conjunction with Cruise Control.Net to do installs on staging environments?
I use MsBuild to build, and part of the build process runs Wix to create an installer(MSI) which is used to deploy to production.
I wrote up a little sample of templating configurations for different target environments with msbuild: http://blog.privosoft.com/2010/10/msbuild-environment-sandboxing.html
We use CC.NET & MSBuild to build and then also to publish to our dev and stage environments, however we do not have the push live on CruiseControl.NET, we run that MSBuild by hand. We just thought it would be way to tempting with a button to publish live ;) It took probably 2 or 3 revisions to get our MSBuild set up right. But now everything is in one file, and everything is based on Targets and Properties to do all the work. About 6 months ago, was what should be the last update and that was a multi-server push so we are ready for scaling up. We can now push any combination of parts to any combination of servers. So if we want 5 database servers, 3 contenet servers, and 2 web servers we have that ability. No need to use anything else. MSBuild can do it.
I created a deployment system where a central coordinator can:
- identify the right target server for a given component (e.g Windows service goes to a given server, web services go to another, etc.)
- perform a PsExec of a deployment MSBuild script on the target server
- the deployment MSBuild script is responsible for:
a) downloading the right component package (in my case a .zip)
b) backing up previous versions of the component
c) extracting the package to the right place
d) tailoring the installation steps to the type of component to deploy (e.g. needs to perform an Exec task of installutil.exe on a Windows service )
e) logging the result of the deployment
This system is built using a mix of:
- core MSBuild tasks
- [Tigris MSBuild community tasks][1]
- [MS SDC tasks][2]
- and custom tasks
The system allows us to perform consistent deployment of complex apps across partitioned environments (e.g. DEV, QA, UAT, etc) made of virtual servers.
I use MSBuild to build a fairly large client/server application. I use InstallShield 2008 to create a separate client and server install set.
By adding a custom target into the build process you can combine the creation of the installers into the build.
I would recommend that you create and test the build and the installer separately, before attempting to integrate the two.
I know this is an old question... but...
I am currently using MSBuild with MSBuild Extension Pack (http://msbuildextensionpack.codeplex.com) to do my entire deployment. The database portion is handled with the VS database command-line tool (vsdbcmd.exe - http://msdn.microsoft.com/en-us/library/dd193283.aspx). That Extension Pack is pretty amazing, and is letting me build web sites, app pools, Windows services, update config, and much more.
I've also put Team City agents on the test servers, so I can deploy as part of a build chain (introduced in version 7 of Team City). And running my deploy MSBuild script is super easy from Team City.
I used to use MSBuild, now I'm using PowerShell. MSBuild is a build language. It is painful to script in. There is a lot I wanted to do in it that were difficult and sometimes impossible.
Over the past year, I've created an PowerShell module somewhat equivalent to MSBuild Extension Pack called Carbon.
I strongly, strongly encourage everyone out there to learn and use PowerShell.