They are needed to run the application locally (and on the server), but the file(s) is specific to the particular application installation. One thing that invariably happens is that there is one or more dynamic files in a project that shouldn't be deployed to the server. But for many static sites like my product sites or as in this case a small static site project that is code managed and staged through other mechanisms often don't warrant a dev ops setup and for those types of scenarios push button Web Deploy still remains a good solution. Yes I know - push button deploy is often frowned upon. Web Site projects and simple Web Deploy often make a good solution and Web Deploy is one of the easiest and quickest ways to publish from Visual Studio when you're not dealing with. In this case the 'site' is the final output from an Angular ng build command in it's own dedicated project folder, which is part of the larger Solution as a Web Site project. So the Web Site project is just one other project that's published. I don't even use Visual Studio for the Angular development ( WebStorm all the way) but other parts of the project live in Visual Studio and deploy to a separate server. Most of my product sites, info pages and a host of small client side samples are all simple apps that don't require any fancy 'DevOps' deployment mechanism, and in these cases Web Deploy often offers a simple solution to quickly get content updated on live site.įor example, in my current requirement, I have a completely static Angular project that sits on its own dedicated static site and communicates with an external API endpoint. This post is a self-reminder, so I can find this information in the future: I still use quite a few Web Site Projects in Visual Studio for very simple, all static sites.

Visual studio auto format