We use Nant and devenv.com to build all our assemblies including the website project. Then we would use aspnet_compiler.exe to compile the published website.
Is this the correct way to do it? Historically, we always used the aspnet_compiler with plain vanilla website folders, but I'm not sure if this is really the correct tool for publishing websites that are part of a website project. It sort of feels wrong to have to do this as a 2 stage process using 2 different tools.
Using aspnet_compiler.exe is one of many ways to publish a website:
http://forums.asp.net/t/1544792.aspx#_What_is_the1
Since a web project can be compiled using msbuild (instead of devenv.com), you can also create a custom msbuild target to publish your files:
http://www.digitallycreated.net/Blog/59/locally-publishing-a-vs2010-asp.net-web-application-using-msbuild
In this way, you can combine the compiling and publishing of the web site in one step.
Related
So what I'm trying to do is build a .NET Core app with MSBuild, and have it create the web deploy folder but without automatically putting it in a zip file. I can do this for .NET Framework apps by using /p:WebPublishMethod=Package and /p:PackageAsSingleFile=false, it creates the same folder structure but without adding it to a zip file. However with a .NET Core app, it seems to ignore this flag and always zips up the final package.
The reason I do not want it zipped up is I need to add a number of "custom" files to the build before I can deploy it. I can't add the files during the build itself because we have a number of different clients, and they all share the same "base" software, and then the client specific files need to be added afterwords. So I want to build the "base" software, then be able to copy the output folder, add the client specific files, and then zip up that build to be deployed to IIS. This saves a tremendous amount of time because the alternative is doing a new build for each client, even though 95% of the software is the same.
So is there a different way to accomplish this with .NET Core apps?
I've been testing with MSBuild via command line. The solution has a mix of .NET Framework and .NET Core asp.net websites. This is what i'm running:
msbuild.exe "Solution.sln" /nologo /nr:false /p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=false /p:SkipInvalidConfigurations=true /p:PreBuildEvent="" /p:PostBuildEvent="" /p:BasePackageLocation="C:\Temp\BuildOutput" /p:platform="any cpu" /p:configuration="release"
This works for the .NET Framework websites, but the .NET Core websites continue to be zipped up
And just a note that the BasePackageLocation is a custom property that sets the PackageLocation to "$(BasePackageLocation)\$(MSBuildProjectName)\" so that each website is put in its own sub-directory
So is there a different way to accomplish this with .NET Core apps?
Sorry but the answer could be negative. This is one issue about publishing .net core projects, it has been reported to Product Team, there might be a long way to go before the fix.
For web deploy package mode in .net core, you'll get WebApplication.deploy.cmd in the same folder where the .zip exists, many commands in the xx.cmd are associated with the xx.zip, so it's not recommended to manually do something to unzip it.
I suggest we can track the issue there(DC) and I will update the answer if there's any update or fix :)
Is this possible?
We currently have build definitions and release definitions setup and working for Web Applications. However we have a lot of older web site type projects and will not work with the current build and release definitions that we already have setup.
Is there a way for us to get the web site projects to work with the build and release definitions in TFS?
Thanks
Recently changed my steps for the build definition and now that build is successful but the release still fails.
Build definition Steps are:
Nuget Installer, Copy Files, and Copy and Publish Build Artifacts
Release definition Steps are:
Powershell on Target Machines, and Windows Machine Files Copy
As web site projects needs bin folder and TFS doesn't want them to be stored in source, the best way to achieve is to convert web site projects to web application.
Best practice: Converting to web application:
https://msdn.microsoft.com/en-us/library/aa983476.aspx
But they made a workaround maybe you can try:
https://blogs.msdn.microsoft.com/tfssetup/2016/09/21/building-a-website-with-tfs-build/
I have a website project and some other projects that are tied up via a solution file. When I build the solution using visual studio, it does not create precompiled version of website but using msbuild to build the solution creates precompiled version.
We don't use precompiled code to deploy on servers so this version is not required in our process.
And this takes a lot of time to get created.
So how can I avoid creation of pre compiled version? Is there any switch or task that I can use in msbuild scripts to build the solution.
I need msbuild to simply build the solution.
currently the command that I am using is:
msbuild "ABC.sln"
MSBuild on the command line features a /t switch, which allows you to define build targets. You would use this switch to target all the other subfolders in the solution, leaving the website untouched.
MSBuild Command Line arguments on MSDN
I have an asp mvc project. I'm wondering, what's the difference between building the solution and then copying bin and all other views/scripts/images/style sheets and publishing (besides the obvious work of copying files). I'm asking because i want to automate my deployment with rake and I can't use web deployment because it's not compatible with mono.
Depending on your version of Visual Studio and settings, Publishing typically does two main things in addition to the build
Packages the solution
-- usually into some standard format (WebDeploy, Web Project)
Automates deployment
-- typically hooks something like MSdeploy ("web deploy") to synchronize the site with a local or remote IIS setting
So in terms of what you are deploying, there is no difference. The build and output files are the same. Publishing is simply allowing a developer a simple path of packaging + deploy, which you are handling with rake.
BTW Have you looked Uppercut this tool could be very useful in your build process.
I have recently upgraded my .Net 3.5 solution containing some C# code projects and a ASP.net web site project to VS2010 (from VS2008). It is building and running fine inside VS, but I get some problems when trying to build it on my server with MSBuild 4.0 via TeamCity. It seems like the projects that are referenced from the web site are not built. This was all working fine before I upgraded to VS2010, MSbuild 4.0 and Windows SDK 7.1.
Inside the msbuild script that I use to build from teamcity I have defined project references for the web site like this:
<ProjectReference Include="..\src\trunk\DataAccess\DataAccess.csproj">
<Project>{C43242F4-7286-4BEC-9A27-001D6FC14860}</Project>
<Name>DataAccess</Name>
</ProjectReference>
When I try to run the build script I get an error message saying that it could not find the dll file when trying to copy it from the bin folder of the referenced project into the bin folder of the web site. This is happening because the referenced projects are in fact never built at all (No bin folder exists in the project dir).
Does anyone have a clue what may cause this? I am not very experienced with MSbuild, so I may have overlooked some important stuff. Is it not so that MSbuild will automatically try to build the referenced projects if no project output is existing?
Will be thankful for any help!
I would need some more info to guide you on this, but off the top of my head try adding
/toolsversion:3.5
to your msbuild call.
I found another post on this website describing your exact same problem. I also ran into this same problem too.
This blog on the MSDN Website describes the problem and the work-around. Basically it's a limitation of solution files which are not in an MSBuild format, but just a fancy text file. And the real thing is, that the dependencies need to be specified in the project files them selves not the solution file. ahhh... just read the link it explains it a hundred times better than my answer here.