I have a large solution with 10+ web applications and 10+ console and windows service applications.
When building All.sln, in the drop location, i've got single folder with all console application dlls, and web application dlls mixed.
Also, i've got _PublishedWebsites folder, which contains nicely separated web applications in their own folders, ready to deploy.
How to get console applicaitons in their own folders, each with only necessary referenced dlls, just the way web applications are separated in _PublishedWebsites?
Looks like it's possible with custom 'master' msbuild file:
msbuild SLN and still get separate project outputs?, but how to achive the same with regular TFS 2010 build?
there's a NuGet package you can install that will do this.
see http://www.nuget.org/packages/publishedapplications
Related
When we deploy our ASP.NET MVC application all sources, controllers, views, etc. are copied.
This is not a problem when we deploy on our server, but when we are going to deploy a copy into external servers and we don't want to share our code.
Does not exist a tool to package into libraries? .NET Core seems to deploy into DLL files, but I don't find that functionality on ASP.NET MVC.
Does not exist a tool to package into libraries?
Yes.
This is what publishing the application does - it prepares the application for deployment. When you publish, it will compile the source code and prepare only the assets your application needs to run into a deployment folder.
It compiles the source into libraries. Views are only compiled if you use the precompile views option, otherwise they are distributed as files.
Use the Publish tool to deploy to a local folder. The exact options available depend on your app type. In Solution Explorer, right-click your project and choose Publish, and then choose Folder. For more information, see Deploy to a local folder.
Tutorial: Publish your Hello World application with Visual Studio 2017
You can combine publishing with IIS Web Deploy in order to easily automate the process of deploying your web site.
In my solution I have a basic ASP.NET MVC website and a Wix Project. To identify the files that need installed I'm using Heat (a Wix component) to index the build output. This is part of a post-build event. It works perfectly on my local machine when building in Visual Studio 2015.
My problem occurs when checked-in and the CI (TFS Build) builds it. The differences are:
The contents of the bin folder is placed directly in the build folder
The rest of the website is placed under a new _PublishedWebsites folder
This means many of the references get broken. For example when dropping the _PublishedWebsites folder into IIS breaks (as .net cannot locate the contents of Bin)
After much research on the subject, and many attempts to pass MSBuild parameters, I'm reaching the end of my efforts.
Is there a way for a build in TFS to leave file locations intact without copying and creating new folders?
If not what is the recommended way to get a deployment ready site (in a single folder) from TFS?
Adding a Copy Files task to copy bin folder to $(build.artifactstagingdirectory)\_PublishedWebsites, check the screenshot below:
I have a website, a windows service, and some shared class libraries in a single Visual Studio solution. I use Octopack on both the website and windows service, and on my machine these builds work as expected.
When using the TFS Build Server, the website nuget package is generated as expected, but the windows service nuget package contains all files from the website, as well as the service. E.g. it includes the _PublishedWebsites folder as well.
This is because TFS uses a single location to build projects.
What is the best way around this?
I know this question has since been closed, but I cam across this issue and solved it in a different way.
My solution is compromised of a number of websites and windows services and had the same issue of the OctoPack created nuget packages including all the solution assemblies from the 'pooled' output folder when building with Team Build. The reason the nuget packages get all the assemblies is OctoPack uses the outdir msbuild argument as the location to include assemblies from.
The way I got around it was to use the msbuild argument GenerateProjectSpecificOutputFolder=true. This instructs Team build to create a folder for each project in your output folder in the same way Visual Studio uses the bin folders under each project when building locally.
My build definition msbuild arguments looks like:
/p:GenerateProjectSpecificOutputFolder=true;RunOctoPack=true;OctoPackPublishPackageToFileShare=\\<NugetServer>
I currently just push the packages onto a shared folder but the OctoPackPublishPackageToHttp and OctoPackPublishApiKey parameters can also be used.
The benefit of this solution over the one above is you don't need to specify the files to include the nuget package.
Hope this helps someone.
I ended up using this nuget package to ensure the console app built to a seperate directory on the TFS server.
https://nuget.org/packages/PublishedApplications/2.1.0.0
I then had to specify in the nuspec file, which files should be included for the console app. e.g
This works and I can now deploy using Octopus deploy.
The downside of this apporach is that the PublishedApplications build only works on the TFS build server, so I can't build the project locally in release mode. Still looking on how to overcome this.
The packages created by a TFS 2010 Build only contain our Sources, not the binaries. When this is (automatically) deployed to IIS, the site does not run because it is missing DLLs that are created during the build process.
We have a Web Project created in VS2010. If I select "Build Deployment Package" from a right click in VS we get a zip file in the obj\Release\Package folder that contains the fully build site.
However, if ask our TFS build process to create the package by adding "/p:CreatePackageOnPublish=true /p:DeployOnBuild=true" to the MSBuild arguments (as advised in amongst other places here) we get an zip file in _PublishedWebsites\_Package\.zip that only contains the sources.
My best guess is that the CopyAllFilesToSingleFolderForPackage is picking up the files from the wrong place.
I notice a similar issue asked here - TFS 2010 and creating a package - although his workaround in not appropriate in many cases, I'd guess.
My concern is that this is using a built-in, but poorly documented feature of MSBuild/TFS so when it doesn't work you're a little in the wilderness.
It seems that deployOnBuild runs some "package"-like target on each of the projects. If you have built the projects into a separate directory (which the default TFS 2010 build does by default) the packaging won't pick up the compiled files.
One solution is to get rid of the custom output folder for the MSBuild Command within the TFS build workflow. This will cause the compiled files to be located in-situ and be included in the package.
Now the rest of the TFS workflow is require some changes because it'll be expecting to transfer the files from the output directory, and they won't be there.
My .sln file has a website (and a few other web applications). The web applications get published to the _PublishedWebsites directory, but not the website. I am not using a custom build configuration. This happens in both Release and Debug mode.
Any ideas?
During the TFS build it checks the project file for Imports which it uses to define the build requirements. The Visual Studio 2010 import for web projects ($(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets) does not contain a definition for the outputting to *_PublishWebsites* as the Visual Studio 2009 one ($(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v9.0\WebApplications\Microsoft.WebApplication.targets) had.
To solve this you need to edit the web application target file on the build server to enable this functionality.
Additional information and assistance can be found at
http://social.msdn.microsoft.com/Forums/zh/tfsbuild/thread/0bd3b8de-0397-41f1-b43a-5ccdd04f9436
http://social.msdn.microsoft.com/Forums/en-US/tfsbuild/thread/559a53e1-2eeb-48e9-a95f-400154b3333f