We are an ASP.NET shop using Windows Server, IIS, Octopus Deploy, etc. We do not use Azure.
In terms of structure and files, my Angular 2 app is very similar to this: https://github.com/DeborahK/Angular2-GettingStarted/tree/master/APM%20-%20Final%20Updated. There is no .sln file or anything like that as it is not an ASP.NET app.
What steps should I take to deploy my Angular 2 app to a server?
My guess so far is to just to run these commands on the server directly from a command window:
- npm install
- npm run lite
Or maybe try create windows service to run these commands?
You will deploy the way you normally do, but eventually what you're going to need to is to create a dist folder (or whatever you want to name it) that has all of your concat'd files / etc. This is what you'll eventually push to IIS etc. Your original Typescript / etc files of course will never get exposed.
How you get your files to a dist is up to you. You can use SystemJS, Gulp, Webpack.
I'd recommend Webpack personally. Basically nothing unusual, you just only want to expose (publically) those minified/concat specific files for Production. IIS just needs to know where they are, and how to serve the initial index.html (Also, up to you, MVC, .NET Core, etc)
Related
I'm building a selection of servers with .Net core 1.1 that are grouped together in an environment and I use an ARM template to create the various Azure resources I need. Currently however I have to manually deploy the actual servers, rather than having ARM deploy the artefacts for me as I'd like.
The instructions here don't work for netcore apps, but it feels like with the move to msbuild for netcore 1.1 I should be able to do this.
I've tried searching the quickstart ARM template repository, but can't find anything relevant.
The biggest stumbling block seems to be that "Web Deploy for Web Apps" needs a zip file, but dotnet.exe doesn't produce one.
you can zip the output of "dotnet publish" and use this .zip file for the deployment.
Make sure there is no root folder in the .zip. For example:
publish.zip
- bunch of .dll files
- wwwroot
- Views
...
I hope this will help you,
KirK
I've been doing some reading http://vishaljoshi.blogspot.com/2010/11/team-build-web-deployment-web-deploy-vs.html and https://michaelbaylon.wordpress.com/2011/04/13/managing-sql-scripts-and-continuous-integration/ ... etc on automated deployment and continuous integration etc but non of it seems to talk about automated deployment in a classic asp environment and you can't really do proper CI unless you get into automated deployment.
Can MSDeploy deploy a classic asp website? If not ... is it best to just write a build script that copies all the files over to the correct folder and then start up IIS? I've done this using msbuild and the robocopy msbuild extension task. But then how do you handle the different environments (QA, dev, staging, production) there's no web config to put the different connection strings etc ... supposedly msbuild is configuration aware ... but how does that work when there is no web config?
So with all these questions I'm struggling to really move forward with creating a deployment script / module / exe for our classic asp website. Does anyone have any answers / resources / further questions that they can point me in the direction of?
Web Deploy (http://www.iis.net/download/WebDeploy) is the way to go. You just have to customize the deployment script for different environments.
You might find this links helpful:- http://msdn.microsoft.com/en-us/library/ms241740.aspx- "Build" Classic ASP with TFS 2010
MSDEPLOY can deploy anything that can live in IIS. You can create a package from the existing web site, and examine it to see what got packaged. You should be able to use that to determine how to package up your site from sources.
You should even be able to create a Visual Studio project from your sources so that you can use the Web Publishing Pipeline directly. The fact that there is nothing there to compile shouldn't stop you from specifying that your .ASP files are content files.
Checkout using cruisecontrol.net, we use that for our automated deploys along with msbuild and it works great. We are a .Net shop but it's basically the same thing. Cruise Control can run scripts and does handle the web.config / global.asa transformations pretty good. As long as you can script it cruise control could handle it.
Depending on your development environment you might be able to hook it into cruisecontrol. We use TFS and it integrates nicely so when we check items into our different branches (Dev, Main, Stage) it auto deploys the site to the appropriate location.
Deploying to our production environment we use MSbuild to move the code. Since it's in another network location we needed something that could go outside and do any server updates necessary.
http://cruisecontrol.sourceforge.net/
The problem is, that when I commit project directory, there is uploaded everything including source code.
Not really sure why you want to upload via FTP? You shouldn't commit your own compiled binaries to source control for deployment though.
You could take a look at AppHarbor, just push your code with git and it will be build and deployed automatically.
more about AppHarbor
Real alternatives to Windows Azure PaaS (web role)?
Does it matter? Since asp.net pages can be compiled on the server, having source files on the web server is sometimes normal so IIS knows not to allow access to them.
That said, uploading output binaries into source control is generally a bad idea - it is better to do the deployment from your build server.
Actually, this is kind of hard.
For months, I've tried to automatize our deployment, without absolute success. For my experience, I can see only way to do that:
Have a build server on your deployment machine (or same network)
A build server will pull out your code from repository, say, once per minute and will check for modifications. If there's modifications, it will execute the build scripts related to this project. I suggest you to use TeamCity, because it is very easy to use compared to CruiseControl (I'm not sure if you can use Git with TFS). You can program your build server for build your solution or project and after, you can execute an msbuild script to copy the files to the production folder (e.g: c:\inetpub\yourapp or \\my_server\inetpub\yourapp). You can use MSBuild's Copy Task to do that.
UPDATE 1: I didn't tried, but if helps, you can push to an FTP server using git-ftp
UPDATE 2: Seems that some guy did some workarounds and successfully deployed his app using git and FTP.
what is the preferred method of deploying a web project? Just copy the dll's after compiling in release mode and registering them? or using NSIS to build an installer or the MS set up project.
I usually use a Web Deployment Project per WebSite or WebApplication, it allows me to manage build configurations, merging, and define pre-post build MSBuild tasks.
You can also take a look to the Microsoft Web Application Installer, it will be really nice, but it still in beta stage, however you can try it...
This depends greatly on where your webapp is going and the experience you wish to provide.
If you deploy to a web host its best to use xcopy deploy and documentation. If you have a real end system its simpler to create an installer to do all the leg work for your customers and maybe save your self some documentation work.
I would recommend investing in setting up a continuous integration process (CruiseControl.Net or TeamCity etc...) As you are probably not only going to deploy it to your customer only once.
Having an automatic deploy at the push of a button is a Godsend. If you invest a few days you can have automatic deploy to a dev-environment every time someone checks in code (and it compiles and all tests pass), set up daily deploys to a test environment and have a button to automatically deploy it to a staging environment whenever you want.
Andreas, I am in the process of getting CC.Net. In the meanwhile, I am using the Web Deployment Project. Using this and going through the set up, it creates a 'release' folder with a bin folder conntaining dll's and also the aspx in the parent folder.
I assume I can now create an MSI file using the 'release' folder or do i need to do something different to create an MSI which i can run on the client server
We have .net46 application that needs to respond to multiple hostnames e.g. localhost.siteA.com, localhost.siteB.com. This is important for us because siteA and siteB are parsed by our code. What we do is:
Point IIS on our developer machine to the web project folder
Edit our hosts file to forward all of these names to localhost.
This is nice because we can make code changes, build, and instantly see our results by navigating to localhost.{site}.com
Now we are trying to develop an application in dotnetcore2 and we need a nice development workflow.
We use the dotnet watch tools and usually run apps like so
dotnet watch run --launch-profile test
This way we can make changes and have the watcher pick them up. This gives us a similar workflow to the one described above for the legacy .net framework.
The problem is we need to be able to use multiple dns names when we do this. Is there a way to make it so that we can specify a hosts file of some sort so that we can still use localhost.{site_variable}.com to access our site?
I realize that in production we use IIS as a revere-proxy and we can setup all the bindings there. But we need a nice way to develop locally. We can't just host the app in IIS for dotnet core... because we would have to publish every time we make a change. We would like to integrate this somehow with dotnet watch run workflow.