I managed to get TFS 2010 to create Web Deployment ZIPs (WebDeploy).
Now the issue is that I have multiple Web projects in the solution and packages are being created for all web projects.
In the projects that I do not want a package, I uncheck the "Create deployment package as a zip". I thought this will prevent MSBuild from creating a deployment package.
BTW I am passing "/p:DeployOnBuild=true" to MSBuild.
Is there a way to get MSBuild only package selected projects and not all Web projects?
Thanks.
Ok. Found the solution. Many thanks to Vishal Joshi for this post.
Extract from the post:
"
Deployment for Web Apps is feasible at both Solution as well as Project build level although when it comes to Solution Build then you might want to make sure that the properties you are passing at Solution level will apply to all the projects in the solution which might not always the outcome you desire. In that situation all these properties can be set within the .csproj or .vbproj files too. You can do that by unloading your project file and in the top <PropertyGroup> section just add above properties as you like:
For e.g /p:DeployOnBuild=True can be added as <DeployOnBuild>True</DeployOnBuild>
"
So, the solution was to remove /p:DeployOnBuild=true from TFS Build process template and update only the project files that require a package.
Related
I have a C# solution with VS 2017, containing an app project, a desktop extension project, and a packaging project. As I mentioned in the answer of this question, I finally get msbuild to create a single bundle with both x86 and x64 for me. However, after I tried to install from that bundle, I found that msbuild actually picked up the wrong package.appxmanifest because they have different version numbers.
So... I have two package.appxmanifest, one in packaging project, and one in my main app project. When I build from the wizard in VS 2017, the one in packaging project will be used, which is correct. When I use msbuild to build with just one platform, it will pick the right one as well, like this:
msbuild .\MyApp.sln /p:Configuration=Release /p:Platform=x86
Only when I use msbuild to build two platforms together, it will use the one in my main app project:
msbuild .\MyApp.sln /p:Configuration=Release /p:AppxBundlePlatforms="x86|x64" /p:UapAppxPackageBuildMode=StoreUpload
I also tried to build the packaging project instead of the solution, but because our desktop extension project is only x86, I will get errors about configurations when building x64.
Questions:
Does anyone know why this is happening?
I am also very confused about how to build multi-platform using AppxBundlePlatforms in the command line. Since I cannot specify the platform, which platform is used to build?
Should I add <AppxBundle>Always</AppxBundle> or <AppxBundle>Never</AppxBundle> to the packaging project?
Does anyone know why this is happening?
That because you have two Package.appxmanifest files with same ID in the solution. When you create the App Bundle with .sln, MSBuild/Visual Studio could not to know clearly which Package.appxmanifest should be use.
I am also very confused about how to build multi-platform using AppxBundlePlatforms in the command line. Since I cannot specify the
platform, which platform is used to build?
Not sure the reason why you can not specify the platform. To resolve this issue, you can try yo build the project file .csproj instead of the solution file. For example, when you build the app project, you can use the command line:
msbuild .\MyApp.csproj /p:Configuration=Release /p:AppxBundlePlatforms="x86|x64"
And then build the packaging project:
msbuild .\YouPackaging.csproj /p:Configuration=Release /p:AppxBundlePlatforms="x86"
Should I add Always or
Never to the packaging project?
If you build the project, no need to add those two properties to the project file, those two properties are used to the solution level and you have a project that you do not want to add to the bundle:
because at the solution level, it’s not clear which app should appear
in the bundle. To resolve this issue, open each project file and add
the following properties at the end of the first
element
Hope this helps.
Before Visual Studio 2015, it was trivial to setup your project to automatically generate NuGet packages. Specifically, you did:
Add a .nuspec file to your project
Enable NuGet Package Restore in the Solution right-click context menu
Edit the project .csproj file and set the build property <BuildPackage> to true
And that was it!
However, starting from VS 2015, MSBuild-integrated package restore has been removed and replaced by the new Automatic Package Restore. While these are all good news, it seems that setting the build property <BuildPackage> to true no longer triggers an automatic package build.
This is a major break of functionality! Is there a way to setup automatic builds of NuGet without using post-build events? Specifically, I'm looking for an MSBuild solution, as it forms the backbone of my build workflow.
Try OctoPack: https://www.nuget.org/packages/OctoPack/
Just add nuget package to your project.
If you want to build it every time you build release, add
to section <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|Whatever' ">
next line:
<RunOctoPack>true</RunOctoPack>
More information about finetuning can be found here: https://github.com/OctopusDeploy/OctoPack
There is a move to Class Library Packages in VS2015 which makes it incredibly easy to create NuGet packages. I've blogged about this before, but essentially it's just a few steps. Note that this is just a RC1 at the moment and not a stable release yet.
Install the ASP.NET and Web Tools 2015 (RC1 Update 1) update to VS2015.
Open VS2015 and create a new Class Library Package project.
Add your code to the library and configure the project.json file with any changes you may need. A default project.json file is used as an example.
Right-click on the project and select the Properties menu item. In the Build tab select “Produce outputs on build”. Build the project.
You’re done. Go to the artifacts folder in your project, in my case “artifacts\bin\AwesomeSoft.TextConverter\Debug”.
You should see the NuGet package already created, and the folders targeting each framework specified earlier.
There is another alternative called NuPack :
How-to-create-a-nuget-package-on-each-Visual-Studio-with-NuPack
It is a nuget package that automatically generate nuget package on build time.
VS4MAc already supports this and you can get it as a extension for VS on Windows
https://github.com/NuGet/NuGet.Build.Packaging
I have an WCF project that if i use the Visual Studio option "Publish" gets published fine.
But if I use the MSBuild parameter DeployOnBuild it does not get published correctly. I'm getting an "Could not load type" error, and all of de dlls are there.
I using the MSBuild in a Build Definition in order to have a Continuous Integration Build.
The build parameters I'm using are:
/p:DeployOnBuild=true
/p:DeployTarget=MSDeployPublish
/p:MSDeployPublishMethod=RemoteAgent
/p:MsDeployServiceUrl=http://host/msdeployagentservice
/p:username=#####
/p:password=****
My main problem with this scenario is that the build targets are the same, and the build definition actualy publishes the files, but somehow they are not the same.
Any insights ???
I dont like to answer my on question, but since it may help someone else is the cause of the problem.
One of the projects had a post-build command to copy the resulting
dll to another project specific directory (its not a reference
because it using dependency injection in runtime).
The dlls did not get checked in to TFS because they are not checkout automaticaly
The
Continuous Integration Build fetches the sources from TFS and the dlls are out of sync
The solution was to checkout the dlls before the build so that the checkin updates them
We current do manual builds/publish from Visual Studio 2010 and we require users to always be running the latest version (check before startup and minimum required version set). I am working on scripting our deployment out and have no issues using msbuild to build/publish. However, I have not found a way to auto-increment the minimum required version when msbuild runs. What are my options to automatically bump this when publishing via msbuild?
I did see quite a few articles on this topic here, but they seemed to be specific to VS and not MSBuild.
Updating the MinimumRequiredVersion Automatically
Introduction to Project Editor
In Solution Explorer, right click on your project and select unload project.
Once the project has become unavailable, right click again and select edit <project_name>.<lang> proj.
Introduction to MSBuild
Properties use key/value pairs to extract information
Using the property name as an alias, you can use $(OutputPath) to obtain the value for the element <OutputPath>.\bin</OutputPath>
We’ll use the following properties generated for a ClickOnce deployment
<MinimumRequiredVersion>1.0.0.6</MinimumRequiredVersion>
<ApplicationRevision>7</ApplicationRevision>
<ApplicationVersion>1.0.0.%2a</ApplicationVersion>
MSBuild Tasks can be specified in the project (*.proj) file and invoked during a build event.
FormatVersion is a built-in task for .NET 4.0 and later that formats the ApplicationVersion and ApplicationRevision into a single version number.
Implementation
Copy and Paste the following code into the opened project file as a child element to the root <Project> element.
<Target Name="AutoSetMinimumRequiredVersion" BeforeTargets="GenerateDeploymentManifest">
<FormatVersion Version="$(ApplicationVersion)" Revision="$(ApplicationRevision)">
<Output PropertyName="MinimumRequiredVersion" TaskParameter="OutputVersion" />
</FormatVersion>
<FormatVersion Version="$(ApplicationVersion)" Revision="$(ApplicationRevision)">
<Output PropertyName="_DeploymentBuiltMinimumRequiredVersion" TaskParameter="OutputVersion" />
</FormatVersion>
</Target>
This code will take ApplicationVersion and ApplicationRevision as parameters in the Format Version task and will save the output by overwriting the MinimumRequiredVersion with the full publish version.
Save and reload your project. Every ClickOnce deployment will now automatically update to the most recently published version.
Many thanks to Kev for their answer which I have basically rehashed here with a little bit of added clarification for any beginners. Here's a blog post I made about the issue that expands even more on my answer here.
Right now, I'm leaning towards updating the MinimumRequiredVersion via a custom command-line utility that will simply read in the project file and increment it. It's the only option I've come up with for scripting out my build.
I'm not sure if you're going about this the best possible way.
I would recommend using a continuous integration (CI) server like Team City that is responsible for deployments. If having the latest version of the source code is a requirement for publishing, then that is probably something you should build into a well-tested CI build configuration, and take away from the hands of the potentially forgetful/occasionally error-prone users.
Since you are wanting to publish using MSBuild and not Visual Studio, I assume you are publishing from a build server or using some sort of script. You can use the Set-ProjectFilesClickOnceVersion PowerShell script to both set the ClickOnce Application Version as well as force the Minimum Required Version to be the latest version. You would want to do this before running MSBuild. My blog describes in more detail how to setup your build server to accommodate publishing ClickOnce applications.
I am pretty new to msbuild and aspnet_compiler.
I am using aspnet_compiler to compile web application project. Now I just saw the MSBuild.exe and noticed that its builds my website into the /mywebsite/precompiledWeb folder. Now why do I need to use MSBuild.exe? Can't I directly use the aspnet_compiler to see if my website can be built properly?
(Not sure if I explained it very well).
msbuild.exe is usually used to build projects and its dependencies. When you have a web application project with a project file, vs can use this to build not only your web project but all the dependencies involved. This would only build your source code files, not the markup files (.aspx,.ascx,.etc).
aspnet_compiler is meant to build a web site project that doesn't have a project file. This said, you can also use it to make sure your markup files are also built for your web application project.
You are correct you can manually invoke the aspnet_compiler.exe tool. But better would be to use Web Deployment Projects to help you do this.