We have the following three things we need to deploy to a Windows Server 2008 farm:
ASP.NET MVC 4 web applications (x3)
.NET Windows services (x2)
I have inherited the deploy process and would like to rewrite it.
Web Applications
When I am in Visual Studio 2012 I have a nice new publishing wizard for deploying web applications. Can this be used somehow? Or taken advantage of in anyway?
Windows Services
Windows Services are Windows Services, so deploying them to a Windows Server should be simple. Right?!
Then there is how to deal with the fact we are deploying to a farm of Windows Server 2008 machines, not just one.
Everyone I talk to seems to have to reinvent a new, custom and complex process that is difficult to maintain and not very malleable, often with custom XML files with all sorts of actions etc that are hand edited. Even psexec gets involved a lot - this smells wrong to me.
Given that at least for the service and the web applications we are doing nothing special whatsoever, what is the simplest way to have a nice, potentially VCS commitable publishing process.
Apologies if this is a ridiculous question, if so please help me understand why!
To be a question on here though, it needs to be answerable. So to summise: what is the easiest/an easy way to deploy web applications and windows services to a farm of Windows Server 2008 machines?
The modern way to do this would be to build your deployment on WinRS (remote power-shell) which uses WinRM for its communication and authentication. WinRM is a bit of a learning curve to configure if you want to step off the golden path though, as I've been finding recently :).
Almost all the configuration services you need (firewall=>netsh, Remote management=winrm, services=>sc, Windows features=>dism, Event Collection=>winecutil, gpupdate, etc) are available as command-line tools and often also directly supported in PowerShell, so you don't need to code anything to the APIs.
Related
I have a strong background in .Net and some Python. After years of PC work, my primary (only) machine at home is a Mac.
I have an idea for an iOS (and Android) app that would be a total labor-of-love, there is basically no monetization possible with it, but I still want to do it. What is the most cost effective way to deploy an app, with Xamarin and only using a Mac?
I will need a database to power the app. I know that I can use MS Azure for a pretty low cost but I know that Xamarin licensing for the SQL Data library is a total budget killer. I know that I could expose web services, but that would require writing the web services with .NET and I want to do this project exclusively on a Mac.
So what are the database options? Can I hook Xamarin directly to MySQL? Can someone please provide sample code for connecting from Xamarin to MySQL? What are some of the better MySQL only providers? I wouldn't need a web host, just DB.
Are there any other potential costs/licenses that I'm overlooking?
You never want to expose your database directly to a mobile client. You always want to have some sort of service brokering your db requests to the outside world.
If your client is simple enough that it will fit under the app size limit, you can use Xamarin's free tier. Otherwise you can use the Indie tier. You should not need the business tier. If this is something that might be a workable open source project, I believe you might be able to ask Xamarin to donate a license.
You will also need an Apple developer license, $99/year, for deployment.
You can use MSSQL, Azure, MySQL, etc to power the server side db. You can write webservices with ASP.NET, PHP, Ruby, etc - there is no reason the server side has to be .NET unless that is what works best for you. You can run a VM on the Mac and run VS2013 Express for ASP.NET, or do it directly from the Mac with Xamarin Studio (not sure exactly what level of support there is for this under Mono, but it is doable). Most of the other options can be written natively in OS X.
Other than the Mac hardware, the only other absolute expense is $99 for the Apple Developer account.
For web services on a Mac with C#, look into v3 branch of ServiceStack. There is also ServiceStack.OrmLite which is a database client (MySQL, SQLite, SQL Server etc), it has a SQLite implementation which will run on the local machine (mobile) with Xamarin.iOS & Xamarin.Android.
My intention is to develop and MVC app driven by WCF services.
I will then like to deploy these to Azure.
Can I go about developing my app and services without any consideration to the fact they will be hosted in Azure earlier on in the lifecycle? Or must I structure it differently?
EDIT: More specifically - am I right in saying I can develop this application just as I would prior to deciding it would be hosted in Auzre?
Based on my research and understanding, it is a better practice to consider your future implementation to azure prior to any development, however even if you later decide to move an existing application to azure, you may need to perform some modifications to your code.
please bear in mind that, Microsoft is currently offering websites in azure that can host you asp application, you may want to read more about that.
here is some links that may help you.
http://www.windowsazure.com/en-us/home/features/web-sites/
http://www.windowsazure.com/en-us/manage/services/web-sites/
The advert that appears on this page as I answer this question says "Move apps to the cloud without rewriting them".
The official position from Microsoft (who pays for the ads), is that you can migrate to Azure late in the development cycle.
The reality is:
You lose a lot of the benefits of could computing if you don't architect specifically for the cloud. This applies to any cloud platform, not just Azure.
There are likely some hidden 'gotchas' that will trip you up if you develop for normal Windows and then try and move it up to Azure. Just this morning I had a developer that was frustrated by errors on SQL Azure that didn't occur on his dev machine. The approach to SQL Azure is different to standard SQL (feature differences, throttling, etc).
There are two 'it depends' that are related:
Are you intending to use cloud services or Azure websites? Azure websites are easier to migrate because they are closer to a traditional web development approach.
Applications with lots of moving parts, or that are subject to high load, need special consideration (regardless of the target platform), so you will want to optimise for, and take advantage of, Azure specifics.
If you have a good reason not to develop specifically for Azure (such as your employers official position, platform portability, etc) then don't worry about Azure for now. If your long-term intention is to run your app on Windows Azure, then code for Azure up front — the effort to take it off Azure (lock-in) will form part of your decision later on.
I'm trying to make an application that will allow a user to initiate builds, see build info etc, and just general TFS based actions.
I've found a few guides on how to use the SDK... http://msdn.microsoft.com/en-us/library/bb286958.aspx
But I can't use the TeamFoundation.*.dll's in the metro/win8 app... http://msdn.microsoft.com/en-us/library/windows/apps/br230302(v=vs.110).aspx
so, is there an alternative? Do they have a separate api? (you can access a tfs project via the web access, providing a web based alternative from doing it all in visual studio).
Thanks,
james.
Windows RT is an ARM based surface and the TFS SDK/OM is only available compiled for x86. So, it will not work.
Windows Surface PRO available later will be x86 based.
The closest you could probably get is if you coded directly to the SOAP web service layer directly. The TFS team is also starting to create RESTful http APIs with light http clients but that's a work in progress that's just starting. That would be the long term approach available someday.
If you're creating a Windows store app, you should note that it's sandboxed. The TFS team is looking into that as we transition toward REST and a more modern REST client.
I am trying to decide what stack to use for a new web based backoffice system. We develop in C# and are going to use ServiceStack and/or ASP.NET MVC. Our customer prefers hosting on a Linux server, so this rules out MVC4 as this is not supported by Mono.
Additionally we are worried about the state of the mono-fastcgi-server needed to run ASP.NET on Mono because of posts like this https://serverfault.com/questions/330298/stopping-fastcgi-mono-server-gracefully-website-content-updating-with-no-need-t and because we find it very hard to find relevant and up to date information about the state of the project. Therefore we hesitate to use MVC3 on mono as well.
Right now we are considering using ServiceStack (with the new Razor views !) hosted in a console app behind and NGINX reverse proxy. This seems work fine and the ServiceStack documentation indicates that this is a viable solution. But what about Mono? Is it stable enough for serious production sites and services, is the garbage collector performant etc? Does anyone have up to date experience with hosting busy server apps (console apps using httplistener) on mono - if so, how does it work, would you recommend it? what version of mono did you use?
Our alternative is to force our customer to accept a windows server, and then we will use service stack or perhaps mvc4 combined with service stack.
So to sum up, what would you do/consider and what are your experiences with hosting servers apps on mono?
ServiceStack.net has always run on Linux/Mono
Note all live demos hosted on servicestack.net are running on an Ubuntu linux vServer. servicestack.net has always been hosted on Linux/Mono for years, in-fact before moving to an Ubuntu vServer from hetzner our old CentOS server had an up-time of 480 days. We consider Mono an increasingly important platform to support as we expect the advent of linux-only clouds to be an important competitive advantage since it allows you to scale at $0 software licensing cost.
Developing on Windows with VS.NET and deploying to Mono/Linux
For all of ServiceStack live demos we develop on Windows with VS.NET but we git-deploy and build and host on Linux. As outlined in our Release Notes we take special care to support Mono as a first-class citizen where we apply normalizing behaviour as much as possible so porting an existing IIS/ASP.NET site remains trivial (i.e. you should be able to copy and run the binaries as-is!) - this extends to the external dependencies we adopt which are influenced by their support of Mono.
All demos including the Razor Live demo is hosted on Mono/Linux
All ServiceStack demos are hosted on Linux, this includes the Razor example which has 2 versions deployed and hosted on Mono, i.e.
razor.servicestack.net - ASP.NET Hosted live demo powered by Linux / Nginx / MonoFastCGI
razor-console.servicestack.net - Self-Hosted Console App hosted behind Nginx Reverse Proxy
You may want to look at this question for different ways to host ServiceStack on Linux.
I am thinking of developing a website using the ASP.Net MVC framework on Linux. I would like to know:
what are the best practises for developing such a site (are they any different for mono/ Windows)?
any gotchas I should be aware of
any (material diffeences) - e.g. missing/proprietary libraries/componenst between Mono and .Net
are there any special directives, modules required to run Mono with Apache?
Are there any performance differences between a site hosted on Windows/IIS and Linux/Apache?
I intend to do most of my development using VS Studio - can the site be developed using VS and then deployed on Linux?
I am aware that this question has been asked several times here on SO. However, most of the questions date back to 2008 or 2009 - which is a very long time in internet time. Things may have moved on since those answers - so those answers may no longer be relevant.
I have to state that I am NOT interested in hosting the site on a Windows server - so I am only interested in what works for a Linux server deployment.
I'am currently working on a MVC 4 app and we are using Mono. If you are just planning to have a basic website, you should go for it. But for more complex flows, honestly, I think you should do a little bit of research first, to see if the features you want to implement are supported in Mono. Things you should consider:
only a set of restricted libraries are supported on mono ( for example, right now we are having some issues due to the fact that the mono libraries (Novell and DirectorySearcher) for LDAP do not support pagination)
the developing environment will be different than your server env ( I am using Visual Studio, we managed to pass this limitation by adding a lot of logs)
we do our publish using FTP, so yes, you can deploy it from VS, using a publish profile set up for FTP
it's free, but it will take a lot of time to research & do special thinks just for the sake of Mono
not a lot of documentation available, because not a lot of people use it, so if you have a specific problem, it will be more difficult to solve
My experience is from 2011, but I am pretty sure you will have to experiment to see works and what doesn't - that's my experience with Mono.
Most of your questions are extremely broad and I think your question will be soon closed.
As for your last question this was the way I did it and it worked (develop in VS->deploy to Linux), but you must be aware that:
just because your code will work in the VS debugger it doesn't mean it will work when deployed;
there is no one-to-one mapping between Mono and .Net. Even when things work it doesn't mean they will work the same way. For example the implementation of the encryption code used for http cookies was very different between mono and .net.