I'm pretty new with TeamCity but have 2-3 years experience with CC.NET-t. I'm familiar with MSBuild but maybe TeamCity has other ways to build things.
I see that TeamCity has a nice UI and great plug-in framework. But I have no idea how can I configure an installer package build.
My questions:
I've checked out the source and built the artifacts (some dll and exe). There is no problem, but
how can I create a zip package "on TeamCity way"? (Project/artifact dependency?)
how can I create a NSIS installer "on TeamCity way"?
Can I download plugins or tutorials? Or I have no other choice just MSBuild?
There are some build runner plugins for TeamCity and you can roll your own but I believe the "TeamCity way" is to do that in your build script... since it's a build server right?
And you might want to check out the MSBuild Extension Pack which has a lot of nice-to-haves stuffs like zipping and registry access and whatnot... which will definitely help with those zip and nsis task.
You probably will need to do this using your own handwritten build scripts.
MsBuild or NAnt will probably offer the best options for you.
If you use MsBuild you probably want to look at Msbuild community tasks.
Hope this helps
Related
I have a dll project which I need to install into the GAC, on our Production machines.
(I wish I didn't have to use the GAC but SSIS insists)
gacutil.exe is not available on the target machines and using "Enterprise.Services" from PowerShell does not work (I don't know why)
My understanding is I should created a msi installer project.
However after installing the Setup and Deploy Extension to Visual Studio (2015 soon to be 2017), I discovered those projects cannot be built by our Build Server because it uses MSBuild, and MSBuild can't build vdproj project files.
What is the correct way, using a CI build pipeline (MSBuild), to create build artifacts, which can install dlls to the GAC, of a Production Environment?
Note: there are several partial answers on SO, but I could not find any, which were up to date/answer my whole question. Please keep that in mind when answering.
You need to break this down into several user stories. You aren't finding partial answers, you are finding actual answers for specific questions. What you ask is more like an epic.
In general I would create an MSI using Windows Installer XML. WiX/MSI can install files to the GAC without using GACUTIL. If you use the WiX Visual Studio extension "Votive" you can create a .SLN / .WIXPROJ / .WXS that can be built using MSBuild. You can then put this into a source control system such as Git/TFVC/Subversion and use a build system such as VSTS V.Next Build, XAML Build, Concourse, Jenkins to automation the pipeline to build the MSI.
I am porting a visual studio project to mono develop. I have a fairly complex
post-build script in a .proj file, which copies various groups of files into the distribution
folder. Can anyone suggest a suitable alternative to this for linux? I tried xbuild,
but it doesn't support itemgroup and propertygroup.
The only way I can think of is to extend xbuild to support them,
https://bugzilla.xamarin.com/show_bug.cgi?id=3055
It is a known bug for a long time (> 6 months). Someone may implement it and submit the patch to Mono team.
NAnt was a possible alternative, but I don't think it worth the while to rewrite your MSBuild scripts to NAnt scripts.
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.
We want to create an .MSI package from a web deployment project in Visual Studio 2008.
Now we want to use continuous integration and we would need the .MSI package build in the nightly builds.
Till now we used standard Visual Studio Web Setup project, but this is not compatible with the MSBuild. So we decided to use WiX.
The problem is that I have not found any good tutorial/documentation about this.
Is there a way to do a WiX installer package from a web deployment project? If yes, how?
Also, I tried to use heat.exe to create the XML for the WiX project .wxs file, but it seems that heat.exe doesn't recognize the web deployment project format.
Thank you for your responses.
Regards,
V.
I wrote a blog post about this recently - http://www.chrissurfleet.co.uk/post/2011/07/01/Using-Packaged-Project-Output-in-WiX-and-Visual-Studio.aspx
In short, its fairly easy to use msbuild to package up your web app and then pass it to heat to generate your installer from.
Hope this helps.
You've probably long since found a solution for this, but to elaborate on Tom Cabanski's answer, you can invoke Visual Studio to build the msi on the command line using "devenv.com" via an external process from within your build. It's not a pretty as using msbuild, but it gets the job done. Below is an example of how to invoke Visual Studio:
"C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\devenv.com" your.sln /build Release
Where your.sln is the solution file for the solution you wish to build, and Release is the configuration you wish to build, ensuring that the configuration you choose actually builds the vdproj project.
Following the successful execution, you can grab the msi from the appropriate configuration's bin, and do what you want with it.
I'd appreciate your response to this with your findings/approach, as I'm trying to decide whether to adopt WiX or InstallShield as the approach to building msi's for Web Applications within TFS Build, or to continue with the approach I just described. I haven't had to opportunity to try WiX out, and my very limited exposure to InstallShield suggests that this is far to involved for my need, which is to produce a simple deployment aid for some relatively straight-forward web applications to the company intranet via TFS Build.
We used WIX on the installers for our last couple of projects and ended up regretting it. I would stick with the VS built-in projects and just invoke the VS IDE from the command line in the CI build.
I m new for msbuild & nant.
How i start this in my envronment : .net3.5
I think you are confused with the two, they are both mutually exclusive. Nant is an open source build framework that targets different versions of .NET. MSBuild on the other hand is bundled by Visual Studio.
Both tools do build the assemblies from the command line and can do numerous sophisticated things such as depositing the build into a folder that you specify. They both use XML to specify targets, compiler options and so on.
The best thing to do is to decide on which to use first and stick with it but it would help to have exposure to both tools. Then read up on it, there are numerous articles and documentation likewise to be found. For NAnt, there's an offline html documents that you can download to read, for MSBuild, there's a wealth of documents found on MSDN.
Hope this helps,
Best regards,
Tom.
Msbuild works on project files, and if you have the .Net framework installed then you already have it. You can invoke it with a command like this:
C:\Windows\Microsoft.NET\Framework\v3.5\MSBuild.exe myProjectFile.proj
there are a whole bunch of options that go with it, using the command line
MSBuild.exe /?
will give you a good list and basic doco on them.