I want to add two applications inside one web role in Windows Azure. I'm using Visual Studio 2010.
There are a couple of ways of doing this.
The azure web role accelerator supports having multiple sites in a single web role (see https://github.com/microsoft-dpe/wa-accelerator-webroles). The documentation online regarding this is a little out of date due to the project having been discontinued. However its simple to setup. Just download the stuff from Github, compile and deploy the project from the download to your azure web-role, this then gives you an admin site where you can setup multiple applications within the web-role. You then deploy your application to there using web-deploy.
You can also add multiple sites to the service definition file, see http://www.wadewegner.com/2011/02/running-multiple-websites-in-a-windows-azure-web-role/ for an example of doing this.
Related
I am currently creating a dashboard for a complex backend that should be hosted on an Azure Cloud Service due to performance reasons. Unlike our older projects we want to implement our dashboard as single page application based on vue.js, but after doing some initial research I am aware of difficulties when it comes to deployment.
The idea is to have a frontend project and an ASP.NET Web Api that offers the respective data for the dashboard. Both projects should run inside the cloud service.
What would be the best approach to deploy single page applications to a cloud service? Since we prefer Visual Studio Code over Visual Studio for frontend-related tasks, it would be great if we won't depend on specific features VS offers.
I am trying to find the proper way of having two asp projects in one hosting space.
Project 1 The first project deals with the website front end, shopping cart, and creating orders. It uses EF6 Code First from Database.
Project 2 The second project is a scaffolding one using EF5, to connect to the backend and display the database entries, and CRUD operations for the manager.
Both of the projects are working fine individually on the local machine. I have also tested them individually on the actual hosting server, and both are working there individually. Both connect to the same database.
Problem Now I am wondering how I can deploy these two projects together on the same hosting space. I am not sure what it is called technically, but what I want to achieve is to have the website available for the end users, and the scaffolding be available for the manager. Both the projects are not using any kind of authentication, and I am interested in putting these to work before having an authentication mechanism for only authorised access to the scaffolding part.
Is it possible to deploy ;
1- a web-api project
2- a website written in Asp.net
3- a WCF service as windows service
in one msi file using/in Windows Web Installer Project (preferably) or in Wix ?
Yes, it is possible using WiX. I maintain an open source project called IsWiX that even makes it somewhat easy. See:
Create and Package a Windows Service using IsWiX
IsWiX Web Site Demo
The concept behind IsWiX is project templates (scaffolding) and graphical designers that give you a project structure and most heavy lifting for your WiX MSI project. The template already contains examples of IIS configuration that merely need to be uncommented out. If you need a Web API and a Web Site you'll have to clone that part of the code and make a few adjustments. For example a static website typically won't be a web application where a web-api will be. Then you'll use the services designer to define the windows service. The fact that the service hosts a WCF endpoint really doesn't matter.
For that matter, one of the really cool things about WCF is it's possible to eliminate your dependencies on IIS. I've seen solutions using this with no dependency on IIS and this really makes creating installers a lot simpler.
I've got a sample project that has several web services and uses them during run time. The application works as intended. The web references are can be see in the Solution Explorer under a folder called "Web References" with the list of web services as single files.
I'm trying to use these same Web Services in another solution but it's not working. I've added the Web Services to the solution and they have appeared under a folder called "Web_References". In addition, the list of web services under this appear with the extension .discomap and have 2 subfiles under them with the same name but with the extension .disco and .wsdl.
These are the only differences I can see. However, in the 2nd solution, Visual Studio cannot resolve the references to the classes from the web services (I'm using the same code as the first solution).
Does anyone know why the web references appear differently and why my 2nd solution is not allow me to use the web references that I've added?
TIA
Update: Following on from the comments, yes the 2nd one is a web site and the first appears to be a Windows Application using web services. Given it's a website, how do I use the web references?
In Visual Studio, I tried a project in both. But there appears to be no difference in the tools displayed in the tool box....
So what the real basic major difference.?
See these:
ASP.NET Web Site or ASP.NET Web Application?
Website is for internet based audience - in this case your concerns(security, etc) are different;
Web application is a software, just like a desktop application software, usually intended to be used for intranet environments. For instance, an HR software could be a web app - that is available on the intranet for all the departments to fill in their timesheets.
Though, a website may contain specific operations, tasks, or workflows.
Checkout: Web site project vs Web app project
WebSite project is compiled on the fly.
In a WebApplication, you need to build a page before you can debug.
However, WebApplication is the way to go, because with WebSite-project, you cannot create a setup project (and conversion from WebSite to WebApplication can lead to problems/bugs).
That's why I recommend WebApplication.
Simply put, a WebSite is worth nothing if the customer is too stupid to install it manually.