I normally do a file system publish on my asp web applications before deploying in them on the web root of my web server myself and visual studio packages my aspx pages seperately along with my apis and libraries into DLLs nicely.
I was wondering how to achieve the same effects with Team Build. As of now, I'm able to run build definitions with the default template and the output I'd gotten are just the binaries DLLs without any aspx pages being generated at all
http://postimg.org/image/occoo03zh/
However I'm getting just the DLLs without web pages in Team Build
http://postimg.org/image/mat7co6vp/
I had tried passing various MSBuild Arguments in hopes that it would have changed the output, but no luck thus far. Anyone knows the exact reasons and ways that I can resolve this? Is this output from TFS build normal?
It hasn't been resolved yet, any insights is very much appreciated.
Asp pages are not compiled, your compiled dll's will be outputted to the binaries directory, but your asp pages will be left in the sources directory. you will need to add a post build activity to copy your asp structure into the drop folder.
Can you confirm this by looking in the build workspace (on build server) and seeing if the structure is correct in the sources directory and that the dll's were created in the bin folder. if so you can then copy that whole structure.
You need to pass MSbuild some arguments to get it to generate the published website as you would see it with a file system publish. See here for something similar done with Visual Studio Online.
/p:OutDir=$(build.stagingDirectory) /p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true
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 :)
I have made a script that uses the following command...
"C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe"
"C:\Repositories\Software\trunk\main\upload\UploadWebsite.csproj"
/p:Configuration=Release
This makes a website pre-compiled the bin directory has lots of dlls in it and tons of .compiled files...
However when I 'right click' on the project in visual studio I am able to 'publish' the website to a folder and this creates a pre-compiled website with only one dll. This is the preferable option im just wondering what the difference between the two is....?
The problem is that for a Website project, the publish feature of Visual Studio compiles everything into one dll, while the normal build operation compiles every page into a seperate DLL.
Maybe these articles can help:
Publishing Web Application with MsBuild
How to publish a web site with MSBuild
I am trying to deploy Orchard using WebDeploy.
Orchard has the following folder structure, Orchard.Web is the root of my web application
When i do a WebDeploy all bin folders that sit outside the root are not included in the package. Is there a way to include them?
Here are my deployment settings used by MSBuild
/p:DeployOnBuild=True
/p:DeployTarget=MSDeployPublish
/p:MSDeployPublishMethod=WMSVC
/p:MsDeployServiceUrl=https://myserver:8172/msdeploy.axd
/p:username=User
/p:password=
/p:DeployIisAppPath=SiteName
/p:AllowUntrustedCertificate=True
By design: you do not want these folders. They are rigorously useless and just an artifact of VS compilation.
You can turn off dynamic compilation if you rename Config\Sample.HostComponents.config to HostComponents.config in your Orchard.Web directory. This would allow you to compile your solution statically and you may be able to get away with not having your source on the server. In my experience though, Orchard doesn't really like running in static compilation mode, and this can have undesired side-effects.
You can WebDeploy an Orchard solution when you are in Release, from Visual Studio. If you look at the project file you will find some custom steps which enable it, like copying all Themes and Modules to the right location.
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.
We have a main web application that references several other projects. Do you check-in .csproj/.sln files into source control? If so, do you use these files for msbuild or do you just include *.cs to build your dll? Does ILMerge help in any way with performance?
You should aim to check in everything that is needed so that someone can take a fresh install of Visual Studio, do a checkout, double-click the .sln file, build and be on their way.
.sln and .csproj are a no-brainer, in my opinion: what happens if you add a new file to the project: everybody would have to manually add the file to their project files if you didn't commit the .csproj file.
ILMerge - no. Not for web applications. Not for the rest either.
Checkin? What about letting visual studio handle it. Now, in general - source control without all relevant files is garbage ;) So, it should include stuff like the project and solution.