I maintain a website written in ASP.NET MVC 5, and hosted in Azure. It's a legacy app that is a real nightmare to maintain, and so I've been asked to start migrating to a new codebase and the ASP.NET Core framework.
Our goals are:
Migrate one page at a time
Don't lose the "F5 debugging" experience in Visual Studio
My initial thought was to use a virtual application/directory, which is supported both in Azure and in IIS Express. The idea is to point, for example, the /Shop page to the new website by using a virtual path. Then when we're ready, move the /Team page and so on. I would add a virtual path for each migrated endpoint until the migration is complete.
To accomplish this I created a new ASP.NET Core project, and I've been trying to edit my applicationhost.config file and trying to start multiple projects from Visual Studio, without luck.
I tried configuring two sites with the same port binding, two apps within a <site> tag and also two virtual directories within an <application>, but I always end up with errors. Either I can't start debugging (Can't connect to IIS Express or The object invoked has disconnected from its clients messages) or I get a 502 error.
I don't even know if this is going to work in Azure, but I know we can't go down this path without proper development experience.
Am I missing some other, better solution? If this is a good solution, is there any way to make this work in Visual Studio?
I would consider creating multiple new websites in Azure, one for each section. Then, as I start working with Shop, for example, I'd leave an almost-empty controller in the original solution, redirecting to your new Sales web site. Using this approach, you can efficiently work with one smaller code base at a time and in the future scale the individual pieces of your site as needed. Please note, that you can host multiple sites within the same app service environment (thus not incurring a lot of extra cost by separating into multiple processes).
Best of luck :-)
Related
I have thousand of SQL Server databases (one for each client). When we decide to push on production, we have most of the time changes in databases, the web API and the web application.
The problem is the time it takes to deploy everything, especially the databases. We are using Code First migration and MVC .NET and SQL Server, all with the latest version. It is a SaaS. And the code first migration process is able to update the database one-by-one.
The API and the web application are deployed very quickly within a few seconds. However, the databases are all updated within about 30 minutes. During that time some users got errors and cannot use the software because the API tries to target non-updated database. And worse, if during the databases update, something fails and stop, the non-updated users are stuck until we fix the issue and update the rest of the databases.
Any idea how to solve this problem and make clients happy?
PS: The web application doesn't access to the database, but only the API.
This question is somewhat opinion-based. The maintenance window approach is the easiest. If you want to do live-updating, another way would be:
Keep a version number in the database
Allow running multiple versions of the Web API side-by-side
Choose which version of the API to use by looking at the version in the database
Determine if the Web API's public interface is stable. If it is not, also find a way to allow running multiple web sites side-by-side and choose which one based on the version in the database
The most maintainable way to accomplish this would probably be to have at least 3 servers:
One backend server which hosts the old version
One backend server which hosts the new version
The frontend server which routes users to the proper backend server based on the current version.
The routing could take place only at login, or you could do something more fancy such as redirecting the logged-in user when an upgrade is detected. Obviously none of this deals with what happens to one particular client during the actual upgrade of that client's database. You'll still need to address that separately.
Currenty I'm in the process of creating c#.net websites (mvc) with VS 2015.
Im setting up my home development environment.
I use VisualSVN for my versionmanagement.
I use VisualSVN Server for the hosting of the versionmanagement.
I want to be able to host my repository as an asp.net mvc website, so that I can see the working running version of my project/mvc website. The repository is inside a directory called trunk (only visible from SVN Server). However I dont know how this can be done.
Can anyone provide me any insights? Can it be done with IIS straight from the repository or do I need to publish from repository to IIS explicitly?
You would need to publish your source/assemblies to a server location with IIS that has a front-facing IP Address (www.mysite.com). There are some free hosting options for Asp.Net if you do a little searching or check the Microsoft spot: https://hosting.asp.net/hosting
You can setup a trigger process to update the website every time you check-in/commit code if you truly need a matching version of the website in real-time with your code commits. Although this is rarely a good idea in single-developer scenarios it might be a good workflow. Don't do this if the public/customers are accessing your site :)
Possible solution to actually hosting within VisualSVN as well: How do I browse an old revision of a Subversion repository through the web view?
This is more of an Architecture question, and I want to know all the possible pros and cons of the approach.
In my org, we have an ASP.NET Application, a Web API Project, and underlying DLLs which calls App Tier which is physically on different server. In ASP.NET Application, for a particular piece, we are having a SPA.
For most of the things (I would say 99 % of the things) , we are making ajax call from our SPA to Web-API to access underlying functionality.
SPA and WebAPI are both deployed and hosted on same Web Server as different applications and WebAPI has reference to underlying DLLs so these DLLs are deployed with WebAPI.
For one of the functionality some server side processing needs to be done on ASPX page's code behind.
I am suggesting to my team to do keep calling from SPA to WebAPI using http client and maintain loose coupling that we have between Application and the dlls via WebAPI, but many (I would say everybody else in my team) is in favor of adding direct reference of DLLs to ASP.NET application, so now these DLLs will be deployed with ASP.NET Application alongside.
Is my suggestion not so good provided ease of implementation that we would be getting with adding direct reference for DLLs in ASP.NET Application? Let me know if I am not explanatory enough.
I would be in favor of using a DLL directly if you could get rid of the Web API altogether. Since it does not sound like you are planning to do that, I think your suggestion to continue using the Web API from your application:
Using the DLL from two places creates a deployment liability: every time you update it, both places must be updated
Changing the code in DLL requires testing the change from two paths - A-D and A-W-D
Fixing a bug in the way that you call your DLL would likely have to go to both A and W, instead of going to W alone.
Of course, the path A-W helps you exercise your Web API component, too, helping you detect bugs early.
I'm trying to figure out how to have more than one solution for a website, where each solution maps to a subdomain on my Azure site?
For example, I have a site called www.example.com, which a solution for that. I'd like to have another solution which deploys to www.sub1.example.com. And yet another for www.sub2.example.com.
I'd like to keep one site, to reduce the cost - is this achievable?
Edit: This question is along the same lines, however the answer isn't really specific and didn't seem to actually solve the question: How to use subdomain in Windows Azure?
If my thinking is right, you are wanting to host (potentially) completely separate (solutions/projects) websites through one hosting package with azure.
We have a system where we use the deployment slots. These are currently in preview with Azure, and easiest managed via the new portal (also in preview), not the main portal.
Go to Azure,
Click into your website instance,
On the website instance dashboard, under the graph, there is a "quick glance" menu - The bottom item is deployment slots. (You may need to be on the standard compute mode for the Deployment Slots ability.)
Deployment slots are supposed to be used for staging/alternative versions of the main site, and can be assigned a custom sub-domain.
Within visual studio, projects can be uploaded to these environments using the standard azure publish method.
Hopefully this can be of some help...
Is there any way to specify a permanent port for ASP.NET Configuration site (Web Site Administration Tool)?
I need to add a link to the ASP.NET Configuration site, but I can't due to the port changing each time it starts.
Its the port for ASP.NET Development server
http://msdn.microsoft.com/en-us/library/ms178109.aspx
I'm not sure that you can.
The Web Site Administration Tool isn't really meant to be "linked" to as such, it's a fairly powerful, unsecured application, that's only really meant to be run by a developer/admin.
The "Considerations" section of the documentation explain why:
The following sections provide some considerations for working with the Web Site Administration Tool.
Restarting the Application When Saving
Most changes to configuration settings that you make in the Web Site Administration Tool take effect immediately. This requires the Web site to which the change applies to be restarted. Because this will cause currently active sessions in the Web site to be lost, you should make configuration changes to a staged or development version of the Web site before publishing these changes to the production server.
Saving Your Settings
Most changes to configuration settings that you make in the Web Site Administration Tool take effect immediately. For settings for which the Web Site Administration Tool interface has a dedicated Save button, leaving the Web Site Administration Tool idle or allowing the Web Site Administration Tool to time out before you click Save will cause your configuration settings changes to be lost.
Time Out
As a security measure, the Web Site Administration Tool times out after a period of inactivity. Any settings that did not take effect immediately and were not saved will be lost. If the Web Site Administration Tool has timed out, close your browser, and then reopen the Web Site Administration Tool in a new window.
The Web Site Administration Tool manages only some of the configuration settings that are available to the Web site. Many other settings require direct modification of configuration files either manually, by using the MMC Snap-In for ASP.NET, or programmatically, by using the ASP.NET Configuration API.
From that you can see that this isn't something that's intended to be kept around.
That said, with a little bit of hacking around, you could probably shoot yourself in the foot achieve what you're after:
If you right click on the ASP.NET Development server task tray item for the admin tool, and select "Show Details", you can see that the virtual directory that the tool runs under is mapped to (something like):
C:\Windows\Microsoft.NET\Framework\v4.0.30319\asp.netwebadminfiles\
If you were to create (and secure) a virtual directory on your application mapped to that path, you might well be able to get this all up and running as you want.
As pseudocoder points out in his comment below, while going down the Virtual Directory route does "work", there are some limitations to the tool that, coupled with the security issues mean that you probably wouldn't want to use it going forward.
If you were to stick with the Development Server option, the tool won't respond to non-local requests, and once you've deployed the site to a proper web server (IIS) for users to access the Admin site won't be running anyway.
It would probably be better if you could explain why you want to use this permanently so we can advise you on some better options - for example the Membership, Profile and Role providers both provide nice APIs for managing user details that can be easily built into a custom admin area.
Tricky one, however I think to get this working correctly, you're going to have to spend some time doing something, and it's probably better for you in the long run to spend that time doing the right thing rather than hacking in the wrong option.
The Development server can be started from a command line, using a commands along the lines of:
call "C:\Program Files\Microsoft Visual Studio 9.0\vc\vcvarsall.bat"
"C:\Program Files\Common Files\Microsoft Shared\DevServer\9.0\WebDev.WebServer.exe" /port:3900 /path:"PATHSITE" /vpath:"PathSite"
The first line sets up the CMD instance to use the variables and path settings needed to run most of the Dev tooling
You'll want to change the path to the DevServer as appropriate for your environment (mine's in \10.0\ for example, and has a 2.0 and 4.0 version).
Armed with this information, you could do something along the lines of:
Add a link to your site to a page called /StartAdmin.aspx or similar.
In that page, you would then need to have the logic to:
Check through the running processes for the instance of the DevServer that was previously used to host the Admin site.
Close that process down.
Spool up another instance of the DevServer with a known port, pointing to the path for the WebAdmin Site.
Redirect the user to this new site.
All of which is possible, but it's not trivial, and you'll find you'll need to be doing odd things with the process your starting, and you'll need to be very careful you don't shut down the instance of the DevServer that's actually running your site by mistake.
However, this would probably take as long as it would to knock up a quick set of user admin screens, and you'd learn something more useful along the way*
* Which isn't to say that learning how to start and leave running a process isn't useful, it's more to say that I'm guessing its not what you're supposed to be learning at the moment, and you should probably be focusing on that ;)