On Premise TFS publish guidance

[SimonOrdo]

Is there any guidance on how to publish an ASPNET Core project using an on-premise TFS server?

We had it working for RC1 using the following:

1. Powershell script "prebuild.ps1" as per the previous Microsoft deployment guidelines: https://msdn.microsoft.com/en-us/Library/vs/alm/Build/azure/deploy-aspnet5
2. Vanilla MSBuild build. no switches or special settings.
3. Powershell script to run "dnu publish" (now, assuming it would be "dotnet publish") to create a directory of the entire web application's structure.
4. "Windows File Copy" task to deploy the directory structure created in update startup class to work with new APIs #4 to all of the target machines in the test environment.

With the changes to project structure (migrating to MSBuild, etc), do we need to make changes to this process? In particular is the prebuild.ps1 script still needed?

Are there MSBuild commands/switches to handle this process more gracefully?

[bveerendrakumar]

Hi,

I am also facing the same issue using VSO Hosted build agent. Can you someone please help?

[SimonOrdo]

@bveerendrakumar ,

Since we will see some changes to the whole build process before RTM, I suspect they aren't looking too hard at this at the moment.

So, I cobbled together a solution that I hope will still mostly work after the move back to MSBbuild. It's convoluted and smells bad to me, but it does work well enough for now. I'm sure it can be optimized, but after trying so many permutations of MSBuild, VS Build, dotnet commands, etc, and finally having found a combination that works, I'm afraid to mess with it too much more at this point.

One thing of note: with the new IIS hosting model for Core applications, it seems that I can't just overwrite website files as I was able to before. I believe this is because Core sites operate very much like regular applications now, so any .exe or .dll in the directory is now "in use" by IIS when the web site is running. That makes any file copy operations to update the site fail. To deal with that, I added some powershell scripts to stop and later restart the particular web site that we're updating.

Also, in terms of prerequisites for my method, on the build machine I have the CORE SDK (and Visual Studio Community)installed. I don't know if the VS install is required, but I would think not as long as you have the SDK installed. YMMV.

Finally, I had to slightly modify my project.json to defeat various "command not found" (path related, I'm sure) errors during build. I also had to add some switches in there to suppress NPM warnings which would fail the build regardless of how I redirected the output inside of powershell (i.e. 2>1). This is what the pertinent section looks like now:

 "scripts": {
    "prepublish": [ "npm install --loglevel=error", "npm install gulp --loglevel=error", "npm install gulp-debug --loglevel=error", "npm install gulp-rename --loglevel=error", "bower install", "gulp clean", "gulp minify:bundle:js" ],
    "postpublish": [ "dotnet publish-iis --publish-folder %publish:OutputPath% --framework %publish:FullTargetFramework%" ]
  }

And, here is the whole TFS lot (each bullet point corresponds to one task in the image):

• This was the most annoying bit - depending on what I tried, I got different and obscure path related errors. Finally I came up with this combo for a PowerShell ccript:

Write-Output "/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/"
Write-Output "/_/_/_/_/_/_/_/_/_/_/ BUILD /_/_/_/_/_/_/_/_/_/_/_/_/"
Write-Output "/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/"

Write-Warning $env:SYSTEM_DEFAULTWORKINGDIRECTORY\your_preferred_build_output_directory\

#redirecting the output here (2>1), otherwise build fails due to warnings.
#also might want to substitute variables for configuration
#needs tweaking and testing to make sure TFS build still fails on compile errors
& "C:\Program Files\dotnet\dotnet.exe" restore 2>1
& "C:\Program Files\dotnet\dotnet.exe" build --configuration Release 2>1

Write-Output "/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/"
Write-Output "/_/_/_/_/_/_/_/_/_/_/ PUBLISH /_/_/_/_/_/_/_/_/_/_/"
Write-Output "/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/"

#might want to substitute variables for various parameters here
& "C:\Program Files\dotnet\dotnet.exe" publish $env:SYSTEM_DEFAULTWORKINGDIRECTORY\ProjectPath\project.json --framework net452 --output "$env:SYSTEM_DEFAULTWORKINGDIRECTORY\your_preferred_build_output_directory\" --configuration Release --no-build 

exit 0

• Windows File Copy Task to deploy StopWebSite.ps1 powershell script to target servers. Contents as follows:

param ([Parameter(Mandatory=$true)][string]$website)

Import-Module WebAdministration

Write-Output "/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/"
Write-Output "/_/_/_/_/_/_/_/_/_/ STOP TARGET WEBSITE /_/_/"
Write-Output "/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/"

& Stop-WebSite -Name "$website"

exit 0

• PowerShell on Target Machines task to run StartWebSite.psq. In the task configuration, enter "Script Arguments" as -website SiteNameFromIISHere
• Windows machine file copy to copy contents from your_preferred_build_output_directory to the target web servers.

Source is *$(system.DefaultWorkingDirectory)\your_preferred_build_output_directory* and destination folder is obviously your physical IIS directory on the target machine(s).

• The fourth Windows Machine file copy task listed in the image is particular to our project. You don't need it unless you have some other secondary file management to do.
• Windows Machine File Copy Task to copy StartWebSite.ps1 to the target machines.

Script contents is:

param ([Parameter(Mandatory=$true)][string]$website)

Import-Module WebAdministration

Write-Output "/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/"
Write-Output "/_/_/_/_/_/ START TARGET WEBSITE /_/_/_/_/_/_/"
Write-Output "/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/"

& Start-WebSite -Name "$website"

exit 0

• Final task is PowerShell on target Machine task to run "StartWebSite.ps1".
  As before, for the "Script Arguments" of the task, enter -website SiteNameFromIISHere

That's it. One final note, depending on what location you copy the Start/StopWebsite.Ps1 files to, you may or may not need to add a clean up task to take care of those files on the remote server.

If you make improvements to this procedure, I would appreciate it if you posted your findings. I scratched out enough time to make it work well enough for now, but I wouldn't call this prime-time ready, so improvements would be welcome!

Hope it helps.

[aspnet-hello]

This issue is being closed because it has not been updated in 3 months.

We apologize if this causes any inconvenience. We ask that if you are still encountering this issue, please log a new issue with updated information and we will investigate.