I maintain a large ASP classic web site (no budget to convert to ASP.NET). It uses COM objects, written in C#. I need to run multiple sites (Production, UAT, QA) on the one web server.
I would like to be able to have each site run different versions of the code base. That would mean having a separate version of the same COM object per site.
However, it looks like COM objects get registered in the server's registry, with no support for separate versions.
How can I use different version of the same COM object with my site running on the same web server?
Related
I am completely a beginner.
I am developing an ASP.NET application called College Management System. So how do I complete the architecture for this so that the application can be used by different colleges?
This application is going to be used by various colleges and universities. So if I get the tips about how the project is deployed to the clients so that all can access the application.
One last question please:
Every college must have their own application, but still all details must be available with the university as well.
University can have control of these colleges.
First of all, you need a Windows server running IIS with the feature ASP.NET.
If you want your application run separately for each colleges, you need different domains (one server or many does not matter). If you want to deploy a project, you can use the build in publisher from Visual Studio (VS).
You need to install web deploy on the server and give it access (depending on the amount of servers, you might need to create multiple sites in IIS). Publish it on each server for colleges to have their own installation. Now you need to create an system administrator panel for universities to give them the ability to make their appropriate changes.
I have a Dedicated Windows Server 2012 lets call it 'A' where my ASP.NET 4.5 website is up and active on IIS 8. Due to the many downtime issues, I want to now move my website to Azure.
I created an Azure VM with an identical environment and copied all files and database. However I am unable to get the website up and running (2 days now) on the VM.
Is there a way using which I can replicate the exact environment that I had in Server 'A'?
You can copy your existing VM (if it is in VHD format) to Azure. See https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-windows-classic-createupload-vhd/ for more information.
If your server is a physical, you can use something like https://www.microsoft.com/en-us/download/details.aspx?id=42497 to do a conversion, and then upload that to Azure.
Lastly, using services such as chef, puppet, or DSC to ensure that server configurations are standard across machines.
We are just starting to deploy our hosted web application in an Azure environment. We have the database running as an Azure SQL Database and the web application running as an Azure App Service Web App (including a continuous WebJob). We are having some significant performance issues with the Web App and I am hoping to get some advice on how to resolve these performance issues.
Here are some key points:
The Web App is deployed as a compiled web application (binaries, markup, *.resx files), not source code
The Web App is deployed via FTP
The Web App has "Always On" turned On
The App Service is running in the South Central US Azure datacenter
The Azure SQL Database is also running in the South Central US Azure datacenter (so database latency should be minimal)
We have an exact replica of the Web App (same binaries, etc.) running on a non-Azure server in a datacenter in Los Angeles (if database latency were the issue, this site would have worse database latency)
Both instances of the Web App (Azure and non-Azure) are connecting to the very same Azure SQL Database (running in the South Central US Azure datacenter)
I have been testing from a workstation in Utah – not particularly close to either web server
On any “cold” request (site has been idle for a period of time), the Azure site seems to be significantly slower. Pages that load quickly from the non-Azure server take a long time (e.g. 20 seconds or longer) from the Azure server. The content is the same, and both apps are accessing the same database – so I don’t believe it is a database issue. I have narrowed it down to two .NET functions that seem to be the problem:
System.Web.UI.TemplateControl.GetLocalResourceObject(string)
System.Web.UI.TemplateControl.LoadControl(string)
The application includes *.resx files for a few different languages. When a request comes in, it uses the culture in the request header to load the correct resources. The GetLocalResourceObject function seems to be compiling the *.resx files on the fly, which seems to take several seconds on the Azure server. I may need to try something like this to prevent Azure from compiling *.resx files on the fly.
Some of our pages load controls dynamically, hence the call to the LoadControl method. These controls are deployed as *.ascx markup, but the code-behind is already compiled into a *.dll in the .\bin folder. Even though the controls are already compiled, it appears that the LoadControl function is trying to compile each control, which takes several seconds on the Azure server.
A “warm” page access seems to go more quickly on the Azure server (almost as quickly as the non-Azure server), probably because the resources and controls are already compiled and still in memory. I have yet to be able to determine at what point the resources/controls have to be recompiled.
I am trying to figure out the best way to make the site respond well, even on a “cold” request. I have tried running aspnet_compiler.exe on the Azure App Service server (via Kudu CMD). That seems to work sometimes, but it has not been very reliable (sometimes it doesn’t seem to work, or the process doesn’t seem to complete). It also seems that, even after compiling the site, the problem returns after a period of idleness.
Our primary objective is to get the Azure App Service Web App to perform acceptably. It seems that the only way to do that is to force the Web App to precompile the resources and user controls so they are not compiled on demand. I have yet to find a reliable way to accomplish this objective. Any help or insight would be appreciated.
We have multiple clients and we use Azure web sites to host our web application. When we upgrade a client to a newer version of our software we have to upgrade all of our clients to the latest version.
We would like to be able to upgrade a subset of clients when we release a new version. This would give us the ability to test that the new solution is working properly before we bring all of our clients to the new version. We would like to offer a beta version option to selected clients so that they can access new features of our software and are aware that the version they are using is still in a 'beta' mode.
When we deploy a new version we would like to create a web site just for this new version whilst leaving the other clients on the more stable previous version. To do this we are thinking of writing a reverse proxy that directs traffic to the different versioned web sites depending on the client.
Can we host multiple versions of the web site using the same Azure web site. (IIS directories) The documentation I have read relating to this does not mention being able to build multiple versions of the web site based on different code bases.
Is there a way to set up the build so that each new version is deployed to a directory on the Azure same web site so we can effectively host multiple versions of our app under the same azure web site?
We could do every versioned build to a new Azure web site but this could get quite expensive as we run two instances so as to maintain a good SLA. It is feasible that we could end up with ten versions in the wild at once, running 20 Azure web sites to support these versions could get expensive. How can we save on costs and give our clients a good experience?
You can have up to 5 deployment slots including production on azure web apps. Each slot can use a different branch of your source control system like git or tfs. If you use any of these two, deploy is also automatic (continuous deployment) and you can swap slots any time very fast with minimium to none downtime. Each slot has it's own url for external access.
To save costs, you can run multiple web apps on the same hosting plan. There's no limit for the number of web apps running on the same hosting plan. For each hosting plan it's possible to have 10 small/medium/large instances.
Set up staging environments for web apps in Azure App Service
https://azure.microsoft.com/en-us/documentation/articles/web-sites-staged-publishing/
Azure App Service plans in-depth overview
https://azure.microsoft.com/en-us/documentation/articles/azure-web-sites-web-hosting-plans-in-depth-overview/
Yes this is possible. In management portal, You need to configure the details for the IIS virtual directory or application in the website’s configuration.
Ref - http://blogs.msdn.com/b/tomholl/archive/2014/09/22/deploying-multiple-virtual-directories-to-a-single-azure-website.aspx
How can I get two separate ASP.NET sites, in this case a Web Site using Entity Framework and Web Service, to use the same local database mdf & ldf?
I looked around and I think that this kind of local DB is called a User Instance - at least they way I'm currently using it. I wasn't sure if it would work or not until I found the below info from the MSDN Library and now I'm really not sure if it will work.
User instance scenarios include:
...
Dedicated ASP.NET hosting using Windows Authentication. A single SQL Server Express instance can be hosted on an intranet. The application connects using the ASPNET Windows account, not by using impersonation. User instances should not be used for third-party or shared hosting scenarios where all applications would share the same user instance and would no longer remain isolated from each other.
Will this work right away without any extra configuration? When I try to add a DB to every successive application, I get a file in use error if anything else is using the DB which leads me to believe that I can't do it this way. However, if I stop the DB from being used, then add it, and then start it up, it seems to work fine. Does anyone have any reassurance for me that it won't be corrupted or experience any errors by using it this way?
Preferably, the mdf & ldf would be stored in the Web Site's App_Data directory (|DataDirectory|). If I do it this way, I don't think I can reliably use relative addressing for the Service unless I put it in a sub directory for the Site, is this correct?
edit: I'm using SQL Server Express because this is an assignment for school, so I pretty much have to use it. If there is a way without User Instance I'll try to do without it.
You can't use User Instance for this. This allows just one client at a time to connect to your database. When your two applications use the same credentials, you get the error you describe. When your two applications use different credentials, you essentially get two separate instances (also not what you want).
Besides, user instances are only supported on SQL Server Express. I don't know what your production environment looks like, but it probably does not run on SQL Server Express?
You should use AttachDBFilename in the connection string of your web application to point to the local database: AttachDBFilename=|DataDirectory|\MyDB.mdf.
In your web service you also use AttachDBFilename but it depends on the deployment location of the web service where to point it to.