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.
Related
I know such questions have already been asked many times, but I am here with my scenario. Kindly do not delete or vote to close.
I have an asp.net application with L2S and SQL 2008 R2 as backend
Using N-Layered architectured
Mostly normal crud operations to be performed.
Use of Sessions and View States
Manual Login / Logout(User and Roles management) , no .net Membership has been used.
No services used yet, might be a later part.
Third Party controls like Telerik or Infragistics also are in use.
I want to know:
Do i need to change entire application to Azure Web Application?
If not, is it possible to deploy it directly over the cloud , on MS or any other, as we normally do in IIS?
If not, Is there any third party migration tool available to make my plain old web application cloud-compatible, without affecting existing codes ?
I want cost effective and easy to go steps?
Thanks in advance
Yes that should be possible. You almost certainly do NOT have to change your whole application.
Linq2SQL is fine, I run an Azure site with L2S without any problems
You'll have to deploy your DB to a SQL Azure database. There are some restrictions, like all of your tables must have a primary key. A bigger list is here: http://msdn.microsoft.com/en-us/library/windowsazure/ee336245.aspx.
Also, when generating your SQL scripts, be sure to select SQL Azure as the database engine type: http://mooneyblog.mmdbsolutions.com/index.php/2011/09/22/generating-azure-friendly-sql-scripts/
What do your N-layers look like? If they are DLLs, it's fine. If they are web services, you'll need to create web roles for them. If they are windows services, you'll need to port them to a worker role.
Most crud and view state and manual authentication code is fine
For session, it depends on what you are doing (memory vs database). But you'll have the same challenges that you would have if you deployed to any web farm
For Telerik, I'm sure they have to have some support for Azure, and I don't think they would be doing anything crazy that would not work Azure. You should check out their website to verify compatibility.
Also, make sure you are not writing to the hard drive anywhere and expecting it to be there later, because instances can be started and stopped and reimaged at any point. If you're doing that, you'll need to change it to use something else like blob storage.
I have an ongoing series of blog posts that walk through some of the steps, which should help: http://mooneyblog.mmdbsolutions.com/index.php/category/azure/
Good luck!
I don't see any hassles to deploy your web application into the cloud.
You don't need to convert your entire application to anything else.
After all you can just try to deploy it now with the trial subscription in Windows Azure which is free for three months.
There is a fairly big stuff of new technology in Windows Azure such as service bus, azure storage, access control service, etc. However it's not necessary to use all them right now. It's prety easy just to move the existing app into the cloud.
You can deploy it to Azure web site.
That should be easier if you don't want to use SQL Azure and cloud storage.
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.
I'm a web developer who's working in a new shop with developers from a desktop background - as such they have certain idiosyncrasies/best practices when it comes to organizing their code - one of which is that separate UI views are isolated into different projects.
So, on the web side of the house, I have a problem with different projects building in different app domains:
1) I have a "portal" project with a default.aspx
In the code behind there is a custom authentication method called from inside the Login_Authenticate event to log into the "business layer" of the desktop application. The business side stores session data in ASP.NET sessions.
2) I have a "viewer" project with default.aspx - this was originally in the portal project as "Viewer.aspx", where it was covered under the same login scheme and authenticated fine, but we decided it would be good to stand on it's own project because it is a separate view.
We added the same machine key to both web.config files so the .NET forms authentication could be passed via single sign on.
I built the viewer project in two different the fashions:
1st Try (it's own URL):
http://localhost/Viewer
2nd Try (a subdomain under the portal URL):
http://localhost/Portal/Viewer
The issue I'm running into is that the session is not being passed between the Portal project and the Viewer project. I know this is because IIS is running them in different app domains. Unfortunately without the ASP.NET session from the Portal, the Viewer is not logged into the business application.
Is there a best practice/is it even possible for running multiple projects in one app domain? Should the Viewer be a part of the Portal application since it requires the same session? Should the Viewer be a separate project that requires it's own separate login into the business layer? Is there even a best practice/guideline for this scenario?
By default session cannot be shared between different applications.
In practice most projects are not separated this way. In my experience most use some sort of n-tier architecture. Basically you have all your "view" code in one asp.net project, any buisness logic/data objects in another dll project, and your data access in a third dll project. The website then just references the other two dlls.
To solve your issue this answer might give you what you want: Sharing sessions across applications using the ASP.NET Session State Service
There is a way to have multiple projects, but one site. That example is a little old but still works, and is how we do our site.
I have web application that are using multiple clients.
I should create one copy of application for all clients or every client should have its own copy.
I am using Asp.net MVC and SQLServer.
What you suggest.
Creating seperate projects per client will be troublesome to maintain while a single project for all clients could be difficult to customize. It is a fine line and your needs will dictate how you build your solution.
One of my more recent projects where we do SAS (Software as a Service) we were able to build our MVC application using a plugin architecture so that each client COULD have their own DLL deployed to the BIN that would enable customizations for just that client (to the Views, Assets or even the Controllers). We are able to leverage a single code base and have many clients, most without customizations and some with minor to heavy customizations.
Every client has a unique URL for their "portal" and most often they have private domains, so http://app.mycompany.com or http://mycompanyapp.com and some are even hosted on our own site, http://hostingcompany.com/client/.
By building an application that can determine what client it is based on the URL we were able to handle all of these cases with ease. When we deploy we have a single code base (deployed just ONCE to a single folder) and all of the sites use that same code deployment.
We run a web farm where we have many .NET Web Servers and have load balancing setup and the sites all have ping pages that our load balancers interact with to determine their health.
Like I said, your needs will determine what the best solution for you is.
Nick , what about database should we use one database every client or should have separate database for each client in my scenario our application is more database centric so there are lot of changes done for each client as per there business roles .
I need to quickly wrap some security around an existing ASP.Net 2.0 web app. After thinking about it for a moment, I remembered that Microsoft created that Membership and Roles paradigm a couple of years back, and that Visual Studio could essentially create everything for you.
Thus I forged forward using the built in ASP.Net Web Site Administration Tool and created a simple little security framework around the application. After setting all of the options, Visual Studio created a nice little SQL Express DB called ASPNETDB.MDF right under the newly created App_Data directory of my website. This works great until you deploy it.
After trying to push this app to my DEV server I realized that it's not going to work unless you have SQL Express installed on the hosting machine. Worse yet, I figured that there's essentially no way this would work under a load balanced environment considering the DB itself will only be isolated to one of the N nodes.
Rather than work to script out the DB and shove it into my existing SQL box...I figured I'd ask the StackOverflow if there is a better solution for simple yet secure ASP.Net websites.
I'd love to maintain the existing model yet have the database become a local, or flat-file DB baked right into the application. For the time being I'm even fine with deploying the flat file with each user or role change to counteract the load balanced sites in PROD.
Is there not a way to create some sort of similar setup with a flat file? I thought that was the point of the App_Data folder?
You could use a custom Role & Membership provider that supports a flat file, like XML. Here is a link to a XML Membership provider, I've seen similar implementations for Roles.
XML Membership Provider
it's not going to work unless you have SQL Express installed on the hosting machine.
Not necessarily. If you still want to use default membership/role providers you can either have the DB server on the hosting machine or have one instance of the DB as a separate server (just change the connection string for providers).
Worse yet, I figured that there's essentially no way this would work under a load balanced environment considering the DB itself will only be isolated to one of the N nodes.
This statement is not really correct in this particular situation.
With load-balancing you will not have isolated database, but rather a separate database server.
I'd love to maintain the existing
model yet have the database become a local, or flat-file DB baked right
into the application. For the time
being I'm even fine with deploying the
flat file with each user or role
change to counteract the load balanced
sites in PROD
If you say that application with proper SQL DB will not scale, I do not understand how flat-file storage can.
You still can keep local SQL Server database and it will work as long as you take responsibility of maintaining the database consistency across different nodes.
In your situation, I would personally use default membership/roles provider as you do now.
But when deploying, just change the connection string to the proper database server.
You will need a database for other stuff anyway, so why not use the same database for all data withing the application (including membership/roles).
Regards.
I found an excellent solution to this here...http://aspnetxmlproviders.codeplex.com/. Using the dynamic XML you can hack out a simple provider based security model in no time flat.