What is the simplest way to distribute an asp.net web application? I tried to look at some of the open source asp.net projects out there to see how they distribute their apps and how they do updates and they seem rather complicated to me (not for myself to perform but for non-technical users). A lot of them entail backing up the entire installed project, deleting specific folders and save parts of their web.config. I am hoping to find a solution that will make the update process specifically as simple as possible.
Thanks.
I am working on a project with a similar requirement now. We decided to use WiX to create an installer that can be run on the server or machine where the site is installed. WiX is incredibly powerful, but takes a bit to get the hang of.
There are plenty of other open source, and paid installer technologies as well. Here is a post with some info on a few.
CommunityServer provides a setup msi that will create a virutal directory, generate the SQL database and populate it with default data. Updating for point releases though is still a manual process involving an update.sql file and having everyone download then merge binary and static file changes.
They probably could have created an update msi too, but because so many people customize CommunityServer, it is probably better to let people merge changes themselves.
Do you mean in terms of breaking up the functionality into tiers that could be handled on separate machines, e.g. having 3 servers for a 3-tier architecture where one is the DB server, one handles middleware and the other handles the requests in ASP.Net? Another point here would be in going from a web server to multiple web servers in terms of scaling up.
Or are you referring to deployment?
It's a web application, man. Serve it publicly, require registration, and move on. Isn't that the point of the web application?
Related
Multiple Asp.Net Framework 4.6.2 MVC/Razor projects within a single solution.
They use Areas, and each project will implement one or more Areas, distinct from the other.
One project acts as the "primary", and includes the global.asax.
The "subordinate" apps can know about the "primary", but not vice versa.
Is it possible to deploy these to the same web site? (on-prem VM).
There would be some collisions, such as the _Layout.cshtml.
Some how I'd have to be able to setup dependency injections for the classes in the "subordinate" project assembly.
Thanks
-John
I don't think this is possible easily, because so much of an MVC site is pre-compiled into DLLs, and yet some of it (e.g. view files) must be actually physically deployed outside the DLL. You are likely to run into conflicts or confusion I think. It's certainly not a reliable, definable process that you could count on in production.
Here are some alternative suggestions to solve the underlying problem, based on what you described in the comments. These are just ideas, some of which I've done or seen done, and might not suit you, but any of them should be a lot easier to manage than trying to bodge the deployment process:
1) Try building the areas in separate projects as you do now, but without all the generic MVC stuff that surrounds it. I.e. Do it as if they were libraries only containing the files specific to their functionality. Then you can package them up as Nuget packages. When they're ready, install the packages into the "main" site to create the combined solution. That way you won't run into conflicts of layout pages etc. If one of the sub-projects changes, then the main site can just upgrade the NuGet package. You can create private NuGet feeds either via Visual Studio Online (if you have a subscription) or on the simplest level via a shared network folder. I think other online vendors offer private feeds as well. We've done that quite successfully to apply some default styles, scripts, layouts etc to all our various MVC apps.
2) Re-architect your solution as a series of separate apps (that's the bit you've already got), but with a central service that provides federated authentication/authorisation (e.g. ADFS, IdentityServer or similar), and a web API (or APIs) that the other sites can call to access other centralised services and functions programatically. I'm pretty confident you can use routing config and shared sessions to make it all hang together as if it was actually one site.
3) Build it all out as just one site, but with clear separation for the various teams about the back-end services, classes etc that they are responsible for, so they don't interfere with each other's code. Each team can check-in code to different branches in source control and only merge to the shared branches for integration/system testing and deployment. You can use a continuous integration server to test the build process after each check-in, and if you have robust code review and gated check-ins you can stop people changing stuff that they shouldn't. You also have the flexibility to release with/without updates from the various areas, if the development lifecycles are going at different speeds.
4) Some combination of all of the above!
We have several different applications built in ASP.NET that run different parts of the same platform. I.e. An administration web app, a public facing web app and some non-web applications (I.e. .exe apps) that all need to perform some shared functionality.
Ideally I don't want to clone the code due to maintainability issues. Until recent we had all these running on the same server so we could just put some DLLs in the global assembly cache (although we never got around to this and did end up with cloned code).
Now we've moved the various parts of the system to separate servers, putting shared code in the GAC won't solve the cloned code issue. Is there a way to share code across multiple servers without making copies?
You want to perform a distributed execution, because you want to launch and executable in a different machine, and this is probably easily feasible doing a shared folder (but you should be really careful about security).
Another solution is to create a web service that exposes a method to launch the executable or run the task you want to share. In this way you have only one place to update the code.
I can think of three options:
A single solution which contains several projects, including another project containing the platform.
Having the platform/engine on a different solution and share the dll with each project (you have to update each time).
Provide an API which is shared with all projects.
Are you guys already connected to TeamExplorer? Assuming your IDE has it. Otherwise try to publish the code to the same server.
Is it good practice to have a production (live) asp.net website that is also a working copy to push updates?
In general this is considered bad practice primarily because the source control repository contains the source whereas the production application contains the result. The two are kept separate for a number of reasons:
Security. If your source is on your production server, it's at risk of being viewed. Maybe this is a problem, maybe it's not. The safe approach is to just not have the source on the production server.
Performance. The result of building the source can be optimized for performance in ways that the source itself generally isn't. In a .NET application, for example, the production deployment doesn't contain debugging symbols. This may not be an issue in your particular application, but it's something to consider.
Multiple Results. Is your source an actual application, or is it information used to build an application? Can multiple versions be built? For example, in a .NET web application, you might have Web.config transforms. These are used at deploy-time to adjust the result of building the source. If the source itself is being used as the live application, these deploy-time modifications aren't available.
Others may be able to articulate this much better than I can, but in general it is considered bad practice, yes. Your particular application may be an exception to any particular reason or may not be meaningfully affected by any particular reason, so I stress the "in general" part.
Depending on the layout of your project, there may be some security concerns. For instance, if you have a .txt file with some sensitive information, keep in mind that it will accessible in your site.
Anything in App_Code or any .cs, .vb, .config, etc files will not be served by ASP.NET, so you can put stuff you don't want people seeing there.
Also, for initial loading performance, you should precompile your site via the VS Publish command or the Web Deployment Project addin (assuming you're working with a web site project). You could create an svn branch for the precompiled, deployable code and use that branch on your server.
You can use services like http://springloops.io or http://deployhq.com to only push certain folders to a server. That gives you a lot of flexibility in pushing code to deployment.
Basically we have many severs running many ASP.NET sites in different app pools. We roll updates every 2 weeks. My basic question comes down to this:
Is using the GAC codebase feature with a URL that we maintain the latest versions of the class libraries on an independent server a good approach to simple updates of all of these sites on all of these servers?
Is there any general pitfalls or potential issues that might arise with this?
I read the Download Cache is used on a per user basis. In this case would all the sites on the server simply use the version in the ASP.NET user download cache?
Would updates occur only when a site starts? What if One site is restarted and all the other sites are using the version in the Download Cache?
Is there anyway to also manage the .aspx/.js/.css/.ascx files in this manner?
I wouldn't like to trust that sort of update mechanism. It would be better to write a set of scripts, or use Web Deploy to push the updates to the servers in a much more controlled manner.
Simon
Ok, so here's the thing.
I'm developing an existing (it started being an ASP classic app, so you can imagine :P) web application under ASP.NET 4.0 and SQLServer 2005. We are 4 developers using local instances of SQL Server 2005 Express, having the source-code and the Visual Studio database project
This webapp has several "universes" (that's how we call it). Every universe has its own database (currently on the same server) but they all share the same schema (tables, sprocs, etc) and the same source/site code.
So manually deploying is really annoying, because I have to deploy the source code and then run the sql scripts manually on each database. I know that manual deploying can cause problems, so I'm looking for a way of automating it.
We've recently created a Visual Studio Database Project to manage the schema and generate the diff-schema scripts with different targets.
I don't have idea how to put the pieces together
I would like to:
Have a way to make a "sync" deploy to a target server (thanksfully I have full RDC access to the servers so I can install things if required). With "sync" deploy I mean that I don't want to fully deploy the whole application, because it has lots of files and I just want to deploy those new or changed.
Generate diff-sql update scripts for every database target and combine it to just 1 script. For this I should have some list of the databases names somewhere.
Copy the site files and executing the generated sql script in an easy and automated way.
I've read about MSBuild, MS WebDeploy, NAnt, etc. But I don't really know where to start and I really want to get rid of this manual deploy.
If there is a better and easier way of doing it than what I enumerated, I'll be pleased to read your option.
I know this is not a very specific question but I've googled a lot about it and it seems I cannot figure out how to do it. I've never used any automation tool to deploy.
Any help will be really appreciated,
Thank you all,
Regards
Have you heard of the term Multi-Tenancy? It might be worth look that up to see if that applied to your "Multiverse" especially if one universe is never accessed by another...
See:
http://en.wikipedia.org/wiki/Multitenancy
http://msdn.microsoft.com/en-us/library/aa479086.aspx
UPDATE:
If the application and database is the same for each client (or Tenant) I believe there are applications that may help in providing the same code/db as an SaaS application? ie another application/configuration layer on top that can handle the deployments etc?
I think these are called Platform as a Service (PaaS) applications:
see: http://en.wikipedia.org/wiki/Platform_as_a_service
Multi-Tenancy in your case may be possible, depending on client security requirements, with a bit of work (or a lot of work):
Option 1:
You could use the one instance of the application, ie deploy the site once and connect to a different database for each client. You would need to differentiate each client by URL to isolate content/data byt setting a connection string for each etc. (This would reduce your site deployments to one deployment)
Option 2:
You could create both a single instance of the application and use a single database. You would need to add a "TenantID" to each table and adjust all your code to accept a TenantID to ensure data security/isolation. Again you wold need to detect/differentiate the Tenant based on the URL to set the TenantID for the session used for every database call. (This would reduce your site and database deployment to one of each)