OK, Apologies if this has already been asked and/or Answered but I'm struggling to find the right situation to the problem that I'm investigating as the correct terminology is hard to come by!
I have been tasked into looking for a Roll-Back solution for our deployment if for any reason we have an unsuccessful release. Other than heavily structuring our source control and, if an unsuccessful release occurs, getting the previous version from the SVN and re-publishing to the Live Server is there any better quick solution?
Is there any quick and suitable way to Roll-Back to the previously released version?
I am mainly focussing on Web Services currently as these are front facing and any problems with these could obviously cause a problem to customers and will need to be fixed ASAP.
Please don't hesitate to provide any suggestions and comments as I am eager to hear of any and all ideas.
Thanks in advance!
why don't you just copy the old directory into a backup directory.
if deployment fails, than just copy it back from the backup directory.
should be easily done with a small batch script or maybe nant for better configuration possibillites
I have always created an installer for my WCF services. I can only assume that this would work for ASMX services.
If you haven't created an installer before, there is a learning curve. I only glanced over this: http://aspalliance.com/622, but it looked pretty close to what I have done. Let me know what you think.
Just a thought but have you considered running versions side by side?
IE: You deploy you new versions under a different URL and then have customers switch to this version in a staged process?
This allows you to control the switch in a more granular manner, not an all or nothing step. It also means if your web service interfaces have changed customers with older versions of the client can continue to function against the old versions.
If you are also deploying client software that is dependant upon the services then you may want to keep the older clients working on the older versions until the client is upgraded.
Related
I'm a total novice on asking questions on this forum - I hope I ask this question correctly.
The problem I'm trying to tackle is this: I have a Visual Studio 2010 project which is for a Web Service. The class which does the work is defined in a ".asmx" file. The class inherits from the "System.Web.Services.WebService" class.
It runs happily on IIS on a server. Clients can make SOAP calls to the Web Service and it actions the requests and sends a response. That's all fine.
The problem is that I want it to run on a Windows 7 PC on which I can't install IIS. So I wish it to run as a Windows Service (if possible). The only "client" of the service will be the user on that PC.
In other words, I wish to run all the code that is in my .asmx as a Windows Service (if possible).
In an ideal world I'd be able to re-use my existing .asmx (if possible), and not have to copy and paste all my code across to a new Windows Service solution.
So my goal is to find the up-to-date way of running an .asmx Web Service as a Windows Service. I'm hoping someone could point me in the right direction on how I accomplish this.
I've done quite a bit of searching, and it looks as though this is very much possible to do. The problem is that a lot of solutions out there, appear to be slightly out of date. Or I've got my concepts rather mixed up.
Based on "How can I deploy my WCF Service without IIS?", I've had a look at a few things.
The closest I've come is this: "https://msdn.microsoft.com/en-us/library/ms751414.aspx". However, in this example, the actual class which does the work (the calculator) is actually contained in the service itself. I would have thought you could have separated them out. In other words, have the service create instances of a class that comes from my .asmx file.
The second closes I've come across is "https://msdn.microsoft.com/en-us/library/bb332338.aspx#msdnwcfhc_topic4", however this is .NET 3.0 and VS 2005. I'm also struggling to understand how to link my existing class into the service.
The other solutions I encounter suggest adding references to "Microsoft.Web.Services3.dll", "System.Web.dll", and "System.Web.Services.dll", although a few people seem to think this is called WSE which was updated to WCF in .net 4.0 and so I should not be using it.
Any pointers as to where I get started?
In an ideal world, you would switch to WCF, as it can easily self-host, host in a service, etc. And there are plenty of examples out there. It is easy enough to migrate the code from ASMX to WCF. But this is 3.5, as NetFX (WCF, WF and WPF were released under 3.5).
With ASMX, you need a server to host with. You can create a simple "server" with the HttpListener class. This may be heavy enough for your purpose.
https://msdn.microsoft.com/en-us/library/system.net.httplistener(v=vs.85).aspx
IIS now has a hostable core, which can be used with newer versions of .NET, but if you cannot install the newer versions and have to leave the client machines at 3.0, it is probably not your best option.
You may be able to dig up old source for Cassini, which was Microsoft's implementation that eventually became the hostable web core.
Back in 2008, someone snagged the server in VS, which might be an option. Note that the version on this page is for VS 2008, which means 4.0:
http://www.codeproject.com/Articles/23939/Light-IIS-Run-Asp-net-without-IIS
Ultidev has a server that is reported to self-host: http://ultidev.com/download/default.aspx
Hope one of these helps.
Just for completeness, here's how I solved this:
In the end I went with running IIS on client PCs and just continued using the asmx.
I found that converting the asmx to WCF to be quite tricky. To be precise, it was the thread handling within the asmx (thread handling coded by someone else), that I found to be quite hard to convert. To explain further the asmx which I was trying to convert, did all its work in a class which inherited from "System.Web.Services.WebService". It could therefore, create an "Application" instance, which it then used to do its thread management.
So rather than try and do the same thing, using "System.ServiceModel" (which doesn't allow me to create an "Application" instance), I thought it easier to just to use IIS on the client PCs. I figured this was a better use of time than recoding a fairly complex asmx. A bit defeatist I know.
Kind regards to all.
I have inherited an existing .Net/angularJS project. We have a need moving forward to allow customization per client, while still maintaining synchronization through version control (in this case, git).
I'm not a .Net developer--my .Net experience is limited to writing a service a couple of years ago, starting the BrowserStack tests for the project, and the occasional foray for code review type activities. I'm primarily a Flash/Flex developer with a fair amount of ASP Classic and some PHP experience.
My preliminary research seems to indicate that I can do what I need to do with a git subtree, but I need to find where the seams should be to separate out the custom stuff from the shared code. Right now, the HTML and JS are in the same directory as the web services. My first order of business will be to separate those out, but I don't completely understand
Why everything's all in one place to begin with
What the implications are of moving things (project settings, paths, etc.)
When I wrote the service way back, I do remember that we had to scrap the service because the server we had the site on didn't support that version of .Net and it wouldn't work across domains so I could host the service on a server where it would work. I know that things have changed and there's now a way to allow that, but I figure that's the sort of problem I should be looking to avoid as I do this.
I figure I can't be the first person needing to make this kind of separation in a project I think started from the monolithic web project template, but because of a short deadline and a lack of knowledge of .Net, I'd feel better if someone could point me in the right direction or at least alert me to some of the gotchas I should plan to encounter.
Are you Trying to decouple the Projects. If so than this might be a good help.
http://www.codeproject.com/Articles/439688/Creating-ASP-NET-application-with-n-tier-architect
One of my recent project was almost the same that you mentioned above, So I ended up scrapping the old version and Create a brand new Project and Decoupled the related stuffs in the solution.
The best way of understanding stuff is to make sure you seperate the Client Side (Javascript/Htmls/CSS) and Server Side (EF/SP Calls/DTOs etc) by creating different project to the same solution.
Hope this Helps.
So I kept digging, and I finally found a pair of tutorials that address exactly this issue.
Creating an empty ASP.Net Project Powered by Angular JS Using Visual Studio
AngularJS Consuming ASP.NET Web API RESTful Services
In a nutshell, you copy the client's url from the properties panel to the service properties panel and add '/api' to the end of the URL and allow VS to create a virtual directory for you.
Now for my next trick, figuring out how to publish it...
We are writing simple architectured software in C# 3.5.
What I was searching for is for easy updating framework/application...
We don't have COM components, Servicdes to install or whatever, so basically what we need is xcopy stuff form one Server side directory to the client. So what the program should do is like a workflow:
Check some location \Server\Updates for manifest.xml
Check the local setup verison
Download all available DLLs (doesn't necessary all need for complete application, so kind of patch stuff) and substitude them with "old" ones.
I'm aware of ClickOnce, of App publishing, also our setup generator supports autoamtic updates (even if noone yet used it, and I don't want to use to not strongly couple ourselfs with that technology).
Do you know some app or technology, that I'm not aware (actually listed in question) which could better fit our needs. ?
Thank you in advance.
So, after the comment, the answer:
I would look at this SO post.
I looked wyWuild and the AutomaticUpdater controler some time ago. It really looked great.
EDIT
I just remembered that I chose to use AppLife Update in the end. It's more expensive but the features are extremely good
We have several EC2 instances behind a load balancer. Each server has several ASP.NET applications deployed to it. I'm looking for an easy, realtime, automated way to deploy new compiled code to all instances simultaneously.
I've seen solutions using source control repositories like SVN or Git, but this doesn't seem like an appropriate use of the technology for us since we're deploying compiled code to the EC2 instances - not source code.
I've also set up Dropbox to accomplish the sync. It somewhat works, but has its quirks. For instance, you need to build your directory structure around the "one root sync folder" limitation. Any other reason why we definitely should NOT use dropbox for this?
Writing a custom application using the S3 API is an option, but we'd prefer a third party solution over writing more code.
This seems like a common scenario, but I haven't found any good solutions yet.
Elastic Beanstalk seems to be the best route to go now. You simply push your web deploy project to an elastic beanstalk environment and it deploys code to all of your instances. (It manages auto scaling for you.) It also makes sure that new instances launched will have you latest code and it keeps previous versions which you can easily roll back to.
If your asp.net website needs to be auto scaled on AWS, Elastic Beanstalk is really the best end-to-end solution.
Since these are ASP.Net applications and IIS, why not use Web deploy. It's MADE for this.
http://www.iis.net/download/webdeploy
Web Deploy allows you to efficiently synchronize sites, applications or servers across your IIS 7.0 server farm by detecting differences between the source and destination content and transferring only those changes which need synchronization. The tool simplifies the synchronization process by automatically determining the configuration, content and certificates to be synchronized for a specific site. In addition to the default behavior, you still have the option to specify additional providers for the synchronization, including databases, COM objects, GAC assemblies and registry settings.
You can use Git, Mercurial or SVN to push compiled code to the servers, or to have the servers fetch code. Source control is not only for source code - it can be used for files of any type.
Also, one way around the Dropbox issue is to use multiple DropBox accounts if that's the issue. But Dropbox is a pretty easy solution because then you never need to write any code. As long as Dropbox is up, it will work.
You might want to give AppHarbor a try. We take care of managing ASP.NET application servers, loadbalancers and all the other required infrastructure, leaving you to get on with developing your application. We also provide a convenient way for you to push new versions of your app using your choice of Git, Mercurial, Subversion and TFS.
Git or mercurial will do a good job at that, subversion is bad at handling blobs.
And you get very nice control and assurance, that the code got deployed everywhere by looking at the revisions.
Seems obvious but, shared filesystem? Or push out with scp or rsync?
I work with two other developers for a medium-sized company writing internal applications in asp.net. We have about 10 discrete web applications, about 5 class libraries, and probably two dozen assorted command line and WinForms apps. Management expects us to be able to roll out an application multiple times per day, as required by their business rules du jour.
We are currently (mostly) using Microsoft.Net 1.1 and SourceSafe. When we need to roll out a web app, we get latest from SourceSafe, rebuild, and then copy to the production web server. We are also in the habit of creating massive solution files with 5-10 projects so that everything gets rebuilt and copied to our "master" bin folder instead of opening up each project one by one to rebuild them.
I know there must be a better way to do this, and with Visual Studio 2010 and Microsoft.Net 4.0 being released in the coming months it seems like a good time to upgrade our environment. Does Microsoft have an official opinion/whitepaper on how to set things up? My biggest problem in the past was having a system that worked well with how quickly we're expected to push code into production.
There's a build server for .NET called CruiseControl.NET. You may find it useful as it can be heavily automated.
See "patterns & practices Team Development with Visual Studio Team Foundation Server".
Read the whole thing. It contains things you may never have known existed.
Just for the sake of offering different options, you can also look at Microsoft's Team System. It does cost a good bit and also has a bit of a learning curve. However, we use it where I work, and it makes the scheduling of builds and source control easy. I know some people are totally against everything Microsoft, but I honestly haven't run into any problems with TFS yet. Just another thought.