How to setup a TeamCity build for a ASP.NET 5 project - msbuild

I'm trying to setup a CI server for a website that I'm developing, but I can't find any info regarding how to do it with the new ASP.NET 5.

I got you brother. This took me a few days to figure out. This configuration is on TeamCity v10 for a ASP.NET Core 1.0 RC2/preview2 project. As a bonus, I am including the step where it pushes to Octopus Deploy. You will need to install the dotnet teamcity plugin and the newest Octopus Deploy plugin with Push functionality. Here's an overview of the build steps:
First off, don't try to use dotnet restore to restore the packages. It won't work if you have internal nuget packages that are not compiled as .Net Core. This took forever to figure out. I would ignore trying to use dotnet restore until people have converted everything over to .Net Core or Microsoft fixes dotnet.exe to be more flexible.
Some of the stuff I read said to use the newest beta version of NuGet, 3.5. When I tried this, I would get the following error.
[14:30:09][restore] Starting NuGet.exe 3.5.0.1737 from D:\buildAgent\tools\NuGet.CommandLine.3.5.0-rc1\tools\NuGet.exe
[14:30:10][restore] Could not load type 'NuGet.CommandAttribute' from assembly 'NuGet, Version=3.5.0.1737, Culture=neutral, PublicKeyToken=31bf3856ad364e35'.
I don't know what that means, and I don't care. Use 3.4.4 for now. Fill in the rest as appropriate.
The dotnet publish step is pretty straightforward. Make sure you provide the output directory because you want to use it in the final step. Also, be sure to specify an absolute path by using the %teamcity.build.workingDir% variable because of this bug. Otherwise it will fail to find your web.config file and not finish publishing the entire site. You'll be missing things like web.config and wwwroot!
Finally we Push to Octopus. This was very tricky for me. Note the part that says
%teamcity.build.workingDir%/published-app/**/* => OrderReviewBoard.1.0.0.zip
IF ANY PART OF THIS IS INVALID, YOUR STEP WILL FAIL WITHOUT EXPLAINING ITSELF!!! By invalid, I mean maybe you put a teamcity environment variable (like the %build.number% they show in all the examples) in that zip name that doesn't properly resolve. Or you specify a non-existent path. Or any number of things, you will see an error that says "[Octopus Deploy] Please specify a package to push". That means that one was never generated because that statement failed. I realize you want to have an auto-incrementing build number there. I'll leave it up to you to figure out how to do that.
Don't get all confused by what is running here. Octopus tries to explain it on their site, but it is hidden here. There is octo pack and octo push. The new version of octo pack is running out of sight, based on whatever statement you put in that "Package paths" box. Don't get sidetracked trying to create a nuspec package, or trying to use dotnet pack. These are dead ends for our purposes. Create a .zip file and move on with your life. Finally, notice the additional command line arguments I added. These help you out a tiny bit. They aren't required. Good luck.

We (the ASP.NET team) use TeamCity as the build server. Each repo has a build.cmd file, similar to this one. TeamCity simply invokes that file.
For Mac/Linux builds, there is a build.sh file.

At the moment you can try to use TeamCity plugin for .NET Core projects:
https://github.com/JetBrains/teamcity-dotnet-plugin

Please check these blog posts;
http://blog.coderinserepeat.com/2015/01/25/building-asp-net-5-projects-in-teamcity/
http://blog.maartenballiauw.be/post/2014/12/19/Building-future-NET-projects-is-quite-pleasant.aspx

Since there has been many changes to the ASP.NET Core world and I got asked about it a few times, I wrote down a step-by-step guide on how to setup a CI/CD environment using TeamCity for .NET Core. I think it is especially helpful for beginners.

Related

I made a Nuget Package that I use in other projects. Do I have to wait everytime I update it?

I'm building an Azure Function that depends on another project I'm building that's on Nuget. Everytime I update the nuget project, I publish the updates to https://nuget.org. Then I wait for the validation. Then I update my other project to pull the latest version. It's really annoying waiting for the validation... sometimes a couple times per day.
Is there a way I can use my nuget package without waiting for validation to complete? Keep in mind I'm developing both packages side-by-side on the same laptop.
There are three levels to doing this efficiently:
Whenever possible, do local development within the same solution using project references instead of package references. As zivkan said in the comments, this "inner loop" is fastest. Do this until you need to test the package itself (e.g., making sure it installs correctly).
Use a local NuGet feed if you are able to test the package without hosting it on a cloud repository. (nuget add my-package.1.0.0.nupkg -source C:\somedirectory\localnuget) Visual Studio and the nuget CLI can both be configured to look in a local directory, which makes the testing loop much quicker.
If your Azure functions must get the package from a real hosted repository, use MyGet (or if you want to DIY it, Artifactory) to host your own NuGet feed. Publishing your packages to that feed and consuming them from your function should be faster than waiting for official verification on nuget.org.

Visual Studio 2017 (ASP.NET Core) and Aurelia (ES6) from scratch manually?

Is there a tutorial somewhere that shows you how to install & build Aurelia MANUALLY in Visual Studio 2017?
Why do this?
Ideally I'd like to use bundleconfig.json for as much as I can and
use gulp for those things I can't do in bundleconfig.json.
I'll learn every aspect of the build/bundle/package process as possible instead of having a tool set that up for me. (Makes things
easier to troubleshoot if I know how it is all setup.)
I won't be dependent on CLIs and packages that are not kept up to date. (Several that I've looked at are based on VS 2017 RCs).
I've tried several CLIs and "skeleton" projects but they all have their issues. Some haven't been updated to use the latest csproj.
Aurelia CLI: Project/Folder structure doesn't mirror any standard way of building SPAs that I've seen. Also doesn't mirror what you get when using Aurelia's own "Skeleton Project."
dotnew new spa templates: Though the most promising it's typescript only and not ES6. (Maybe there is a way to switch it easily?)
Aurelia's Skeleton Projects It adds dependencies that I do not need. It also does not work out of the box.
So here is what I've determined since originally writing this question.
My original thoughts with lessons learned:
Why do this?
Ideally I'd like to use bundleconfig.json for as much as I can and
use gulp for those things I can't do in bundleconfig.json.
Answer: I was only doing this because I was trying to embed Aurelia inside of a web api project in Visual Studio. I recommend you don't do this and instead keep it as a separate project. (Separation of concerns)
I'll learn every aspect of the build/bundle/package process as possible
instead of having a tool set that up for me. (Makes things easier to
troubleshoot if I know how it is all setup.)
Answer: Though building from scratch would help me learn about this more it isn't a major roadblock. I was just inexperienced with more modern UI frameworks and their corresponding build processes. (RTFM)
I won't be dependent on CLIs and packages that are not kept up to date. (Several that I've looked at are based on VS 2017 RCs).
Answer: - That happens no matter what route you go. You can wait for a library to mature more if this is a big concern.
The bottom line is my question was based on some incorrect thinking. If you are trying to go this route you really need to ask yourself why and determine if it is worth it. To me it was not. Just go with what works, learn and move on. Oh and don't resist Typescript!
npm install aurelia-cli#0.30.1 --global
create new vs solution in 2017 (ASP.NET Core Web App)
with command prompt, cd into the solution root dir (not wwwroot)
au new --here
select RequireJS or SystemJS (my personal preference)
select option 2, asp.net core
select the remaining options.
Run f5 in VS2017.

DNX on VSO Host Build Controller

When trying to build an ASP.NET 5 DNX project on VSO, I get the following error:
Cannot find DNX runtime dnx-clr-win-x86.1.0.0-beta6 in the folder:
C:\Users\buildguest.dnx\runtimes (119,5): Error : The Dnx Runtime
package needs to be installed. See output window for more details.
Does this mean that we cannot use the host build controller with DNX projects yet?
Found a great guide on how to install dnx on vso host.
https://msdn.microsoft.com/Library/vs/alm/Build/azure/deploy-aspnet5
Added the first PreBuild.ps1 script as a Powershell build step and it worked right away.
Since I still use it, to compile my code, to me, it's not dead.
I integrated some travis-ci config in py project, have a look at my .travis.yml for an update, but I count on my host name, my pc, and my internet connection to serve it as I do since few years:
dnx-install.sh
Note that DNX should be able to build DNX,
from it's source code, even marked as obsolete, and that It would be possible, but painfull, to write some scripts and use mono-roslyn directly ... still not a dead branch to me.

RoboCopy not included in latest MSBuild Community release?

I'm setting up a RoboCopy job using the MSBuild Community tasks. It seems however that the task has not been released, despite it being in the list of tasks on the project front page. The latest release v1.2.0.306 does not include it, but if it is present in the SVN trunk. Am I looking in the wrong place?
I know there is an MSBuild Extension project that also have a RoboCopy task, but I'm already using some of the other Community tasks, and I'd rather not make my build depend on two almost identical extension packs.
The Tigris site seems abandoned in terms of documentation, so I'm attempting to see if anyone in here knows.
In case you didn't notice it: the latest official release on the download page (v1.2.0.306, exactly what you downloaded) is nearly five years old (February 2007).
Since then, obviously a lot of stuff happened in the trunk.
You can download and compile the trunk yourself, or you can use the nightly build which you can download at the bottom of the main project page:
Download The Latest Nightly Build
The latest test binaries and source from the automated build server.
Version: 1.3.0.516 Date: 9/8/2011
MSBuild.Community.Tasks.Nightly.zip
MSBuild.Community.Tasks.Nightly.msi
I'm using this version.
So...yes, you are looking in the wrong place :-)
MSBuild (latest) is also available through NuGet: http://nuget.org/packages/MSBuildTasks
You can install it via GUI or in Package Manager Console run
Install-Package MSBuildTasks

Best mix of aspnet deployment tools

I know how many questions have been asked around this, but I still can't figure out the answer to my question.
I need to deploy an ASP.NET 4.0 site, and I want to do something like this:
Get latest version og the entire solution - a website and a couple class projects that are used by the webapp (I am doing this already using CCNet- not a problem)
Build and deploy in debug config to a test site
Build and deploy in a release configuration to a staging site
If everything looks fine on the staging site, I'll run a script that deploys the release build staging site, to 7-8 similar sites used by different customers on the same server. In the future this will be on another server.
There is MSDeploy (webdeploy 2.0), aspnet_compiler, MSBuild, Powershell (my weapon of choice..) and propably more ... I am not 100% sure what to use where?
I would love to mimick the "only deploy files needed to run the site" from the Vs2010 GUI assisted deployment, and I'd love to have the possibility of not touching some existing folders in the websites that we deploy to.
I feel like I should use MSDeploy a lot ... but I find it pretty hard to GET. I'm reading away in IIS.NET and I've heard the Scott Hanselman/Jon Arild Tørresdal podcast. I am not 100% sure where to start ... and I'm not a MSBuild expert, so Powershell is looking pretty good to me. But I feel I'm missing out on the right tools by going that way ...
What tool would you use in which step??
According to me, MSDeploy is build to achieve all of your needs with much more control. MSDeploy is the product of IIS team and it's far more feature rich.
Answers to your questions
Considerations: Svn as Source control, MSDeploy for deployment
You can use SVN Command line tool to get latest version of your source code in some temp directory and build it using MSBuild command line tool. Then you can create a Deployment Package or a Publish Content Package which can be deployed to specific environment. I am currently working on a project which can basically create a deployment package independent of the environment, means the pacakge can be deployed to any stage/test/live environment. Sample for creating a deployment package is...
msbuild C:\Projects\NimBuildDeployTestApp\NimBuildDeployWebApp/NimBuildDeployWebApp.csproj /t:package /p:Configuration=Release /p:PackageLocation=C:\Temp\DeployPackage\NimTestWebApp.zip /p:EnablePackageProcessLoggingAndAssert=true
Use MSDeploy command line tool to deploy the package as below
msdeploy -verb:sync -source:package=packagelocation -dest:CONFIGURABLE_ACCORDING_TO_YOUR_NEEDS
User Step 2 to build the solution in Release mode using MSBUILD and configure the dest parameter in msdeploy.
If everything seems fine on your staging server, run the deploymentToLive.batch file which will deploy a particular PublishContent/package on your live server. Execute 7 msdeploy scripts in same batch file or else use DFS (which is far more complex solution)
MSDeploy is definitely the way to go. One thing that you may consider is having a deployment package ready which can be deployed onto any environment of yours. What I mean by that is your web.config file won't be similar for all the envrionments, and hence create a deployment package which contains web.confif file for all the environments. Refer to my solution here
Hope this helps and gives you confidence in moving forward to automate your deployment process