I am new to windows azure. I've created simple HelloWorld ASP.NET azure application and published it. I know I can republish whole application in Visual Studio by clicking right button on project and then publish it. But is it possible to update only one file (aspx page, picture etc.)
Thanks!
Regards, Alexander.
I think if you're just learning Windows Azure, the most helpful answer is "You can't." The way Windows Azure works is that to update an application, you create the full package and deploy it again.
This isn't to say that David's answer isn't also correct. I just wanted to directly answer the question of "How do I change just one file after I deploy?"
If you want to update individual files such as images, one thing you can do is store all images (and css, javascript, and any other static content) in Blob storage. This has several advantages:
Easy to upload new files individually, with both free tools and paid tools. For instance: Cloudberry Explorer is a free app, and Cerebrata Cloud Storage Studio is a paid app, both which let you manage containers and blobs individually.
Smaller deployment package, because you've removed images and other large files
Less load on IIS, since image requests go directly to blob storage, not to your role instances
You can't store your aspx files in blobs, though you can store static content like html in blobs. To update aspx, you're basically updating the deployment. You can now do this as an "upgrade" which doesn't disrupt your IP address and, if you have multiple instances, doesn't take down your service during upgrade.
You can either use webdeploy (which should do a selective update of all files) or connect via remote desktop and update certain files yourself.
Like the comment and MSDN says: neither of these two ways are recommended/usable for production deployments. They are only meant as a shortcut for certain development scenarios.
Related
I've got asp.net project. I want publish it in azure platform. My project contains different static content: images, javascript, css, html pages and so on. I want store this content in azure blob storage. So, my questions are:
1) Is there any way to automate the process of migration this content from my application to blob storage?
2) How can I use data retreived from blob storage? Any examples would be great!
Best regards,
Alexander
First off, what you're trying to do could create cross-site scripting (they'll be on different domain names) or security issues (if you're using SSL). So make sure you really want to seperate the static files from the rest of your web site.
That said, the simpliest approach would be to use any one of a number of Windows Azure Storage management utilities (Storage Explorer or Cerebrata's Storage Studio would both work), to upload the static content to a Windows Azure Storage blob container. Then set the permissions on that container to publis read so that anyone with a web browser can access the contents of the container.
Finally, change all referrences to the content to point to the new URI's in blob storage and deploy your ASP.NET web role.
Again though, if I were you, I'd really look at what you're trying to accomplish with this approach. By putting it in blob storage, you do gain access to a few things (like CDN enablement), but as a trade-off, you lose control over many others (like simplified access control via IIS for request logs to tell when someone is downloading your image files a trillion times to try and run up your bill). So unless there's a solid NEED for this, I'd generally recommend against it.
Adding a bit to #Brent's answer: you'll get a few more benefits when offloading static content to blob storage, such as reduction in load against your Web Role instances.
I wrote up a more detailed answer on this similar StackOverflow question.
In light of your comment to Brent, you may want to consider uploading the content into Blob storage and then proxying it through a WebRole. You can use something like an HttpModule to accomplish that fairly seamlessly.
This has 2 main advantages:
You can add/modify files without reloading your web roles or losing them on role refresh.
If you're migrating a site, the files can stay at the same URLs they were pre-migration.
The disadvantages:
You're paying the monetary cost for Blob accesses and the performance cost to your web roles.
You can't use the Azure CDN.
Blob storage is generally slower (higher latency) than disk access.
I've got a fairly simple module I wrote to do exactly this. I haven't gotten around to posting it anywhere public, but if you're going to do this I can send you the code or something.
Our product is an ASP.Net web application. Currently, we use Web Site Projects in Visual Studio, but have been looking into using Web Application Projects for quite some time. I am currently researching them so that we can hopefully improve our deployment process.
We have a base web site that is shared and common between different clients, and then we extend that with client-specific functionality in client Web Site Projects. The client projects extend base, and therefore rely on its contents. To build the full product, we first deploy the base web site, and then overlay it with the content from the client project.
In looking at converting to Web Application Projects in Visual Studio, we were hoping to be able to create the base project, then create client projects and set up references to base. This structure seems to work OK, but when we are attempting to deploy the application from the client project using MSDeploy, only the dll from the base web site is being published. This is fine for some things, referencing the compiled code is useful, but there are other items like images, js pages, htm, etc that is still source that is required for the client application to function. We need more than the compiled code from our base web site.
That all being said, I can think of a few options here:
Continue to deploy in 2 steps. First the base web site, then the client web site to build the full product.
Modify the deployment process to copy the required source files from the base project
Re-architect our model to support this base-client relationship in a different manner. Not quite sure how this would work, and would be the least-viable option.
??
Is there a different option that I am missing? Am I doing something wrong with the way I am setting up my projects? Is there more to making a Web Application reference another Web Application beyond sharing compiled code? If that's the case, why wouldn't you just use a shared class library? Or maybe I am missing something with the MS Deploy process?
I am open to suggestions here as I feel like I am missing something. I don't think our model for our web applications is too unique.
Update: The dual-deploy process does work, but feels a little kludgey. Any other input?
By using assembly WebResource you can Add CSS/JS/Some other File as Reference along with the Code i.e, your Base Project DLL.
If am right you can Add this WebResource in your base project then go through the below link.
http://support.microsoft.com/kb/910442
Like this way, most of the third party tools will access their CSS and JS files.
Try this. Hope it will help.
How is the site "shared" between clients? Does each client ultimately get a different site (ip address, etc) or are they logging into the same site but getting different functionality? You may want to looking into adding ALL the functionality into a single project and then enabling/disabling feature via settings.
If i have correctly understood your question, you'd like to publish also items which aren't compiled (htm, JS, images, etc..).
So, each file in your Solution Explorer tab has its own properties (accessed by F4 key) which let you choose the build action (eg. compile -> will inject the item in the DLL if applicable, content -> will copy the file "as is" to output directory).
I think the build action "content", with the option "copy to output directory" set to "copy if newer", may be the solution you're looking for.
I would carefully analyze what you are sharing between projects and how you share them.
If it is compiled code, the correct way is to extract those classes out into their own namespace and assembly and share the DLL across projects. Ensure you follow OO and SOLID principles while refactoring.
If it is content (js, htm, images, css) that you share, you have a few options here. You can create a separate virtual directory for the content and reference your content with an absolute URL. This helps because later down the line if you ever want to separate out a project into its own website in IIS, you don't have to change the content URLs. You can also have all the content in your so-called base website and then reference the content in the other projects using a relative path relative to the base website.
On the other hand, if it is ASP.NET user controls or ASP.NET MVC views that you would like to share, it is best to create an individual item in each project. This does not necessarily mean there is a separate physical file in that path - you can also add items in a .NET project in Visual Studio that are only reference links.
Regarding the deployment process, I don't think there is anything wrong with the web site projects per se. Web site projects have a purpose that is different than Web application projects, the main being that you do not have to compile your classes every time you deploy code (provided they are in the correct application folders).
I would suggest sticking to the 2 step deployment process with Web site projects.
I would also review the web sites (virtual directories) created in IIS and consider nesting them if it makes sense. And a review of the application pools (whether separate or shared) would not harm either.
Lastly, this is an old question. Please share if you have already implemented a successful strategy.
I am developing ASP.Net MVC websites. Currently I publish (using VS210) the site and upload the published code, bin file, views, css etc.
The only issue I have with this is that the only place I then have the actual source code is on my local machine and backup drive. I tend to work from various places and pull others in to work on projects from time to time and we do not have the infrastructure to synch it all at the moment.
Having the source code on the server can actually be quite useful to me.
But is there any problems with doing this? I presume there is no performance issue as it will be compiled anyway, but what about security?
The web config file tends to store the DB connection - but this is present on the server regardless of source upload or published upload.
Any input appreciated.
Deploying the build outputs to the server is definitely the correct thing to do. What you are looking for is generally called source control. That will let you keep a database of your source, including revisions. It is the first step to enlightened development. You really shouldn't leave home without it.
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)
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?