what is the best way to deploy a winforms app if you know you are going to be doing frequent releases
Click Once is your best bet.
Click Once is great if you know the customer base will always have access to an internet connection and they only ever need a single version installed. This is probably true for the majority of apps.
But if that is not the case then I recommend you ensure that people can install different versions of your application side-by-side. Do not place your assemblies in the GAC or have them share a common resource. This way the customer can have multiple versions installed and they all continue to work. Xcopy deployment would be even better but hard to achieve in practice for non-trivial apps.
I recommend an NANT build script, using NSIS for your setup script. Both are freely available and allow you to have a one-click build process that is fully expandable.
In a corporate network I do the following:
create a strong name key
have all machines 'full trust' any assembly with that key - this can be automated with group policy.
sign the app with the strong name key
put the application on a network share and push shortcuts to the user’s desktops via a script or group policy.
Note: It's given that you've already pushed out the .NET framework. This also can be automated. If you've other resources that need to installed on the client the something like Click once is going to be needed.
Related
Imagine I have a type of "virtual OS" framework in Unity which runs C# code that represent third-party apps the user can later launch. Would there be any way to secure that third-party code to not, say, read or write files to the local storage? A kind of sandboxed security model (maybe via each third-party app being a DLL which is given certain rights or so)?
If impossible to achieve programmatically, is there a way a project could be securely checked via a custom parser to disallow all file-access keywords ("may never include string 'IO'", with one being ok for false positives to be checked manually), or is that impossible to achieve too? Thanks!
I have several C# assembly libraries, which are not strongly named (signed). I would like to make a SxS COM-wrapper over those components using the tlbexp.exe to consume in native programs. Is it necessary to sign them or is there another way to do it?
Thanks
There are strong misconceptions in this question, it confuzzles the roles of two programmers. You are the author of the library, somebody else uses your library and probably works for another company and has no idea who you are. The client programmer. You in turn have no idea how the client programmer uses your library, how many programs he wrote and what he does to deploy your library on his users' machines. You run Tlbexp.exe only to help him write his code.
This is a recipe for trouble, like it is no matter what language or tooling you use when you create libraries. That trouble starts when you make a change in the library and the client programmer has to rebuild and redeploy his programs that use your library.
There is extra trouble in a COM library because by default registration is machine-wide. Which is pretty nice if the change you made is a bug-fix, all of the client programs that use your library automatically get the fix. But it is not nice if the change is breaking and causes the old client program to fail. The standard disaster is that the client programmer rebuilds some of this programs but forgets or ignores some old ones he no longer maintains. The end-user is often the real victim, he's got a program that crashes but two programmers that don't think it is their problem to fix.
What is necessary is that programs that the client programmer does not update keep using the old version of your library so it is unaffected by the change. In other words, there need to be multiple copies of your DLL on the users machine and a program automagically needs to pick the right one.
Thankfully that is easy to do for a [ComVisible] .NET assembly. Either the client programmer, his user or an installer you provide for him can put the assembly in the GAC. Which allows multiple copies of an assembly to exist side-by-side and the CLR can automatically find the correct one. That has two requirements. You need to bump the [AssemblyVersion] of your library, that's standard. And the assembly needs to have a strong name so it can be put in the GAC. That is trivial to do by you, using Project > Properties > Signing and ticking the "Sign the assembly" checkbox. This has no security implications so the key doesn't matter and a password is entirely unnecessary. It is not easy to do by the client programmer so this is something that you must do. Always.
The client programmer also has the option to use isolated COM with a manifest (aka "regfree COM"), probably what you meant with "SxS COM-wrapper". With the benefit that each program he writes has its own copy of the DLL, the way it works by default in .NET. Bug-fixes need to be deployed manually but a change in your library can't break an unmaintained client program. But this is entirely his choice, there is nothing that you can do to ensure that this is done. You must assume that he doesn't use it, and he almost certainly won't at first, so you can't bypass the need to strong-name.
When an assembly is strongly named, its types can only be used from other strongly named assemblies. Since your assemblies are not strongly named, there's no need to sign your COM wrapper.
Signing an assembly makes it possible to place it in the Global Assembly Cache (GAC). This has the benefit of keeping multiple versions side by side, without breaking existing clients.
The alternative is to use the Windows registry via regasm's /codebase switch. Much in the same way as classic COM components are set up, this option registers your COM-visible assembly on a system wide basis.
Since you wish to deploy your COM wrapper via SxS / Registration-Free activation, thereby bypassing the registry and GAC altogether, there's really no need sign it.
I don't know if this is entirely possible as a one click and done option, but what I would like is to automate our IIS MVC development setup for new developers.
Basically, what I am looking for is:
App pool creation if one is not already created (and make sure it is the correct version of .NET 4.0)
Creation of an IIS Application under the above app pool that points to the source code
Figure out if aspnet_regiis -i is needed (in the case that IIS was installed before 4.0 code was introduced)
I am not looking for a publish option as that does not point to the source code. Also, I am not looking to use the built in VS host as I am trying to use IIS to make sure everything is set up appropriately. Maybe I should not impose these limits and do not need to worry about setting up the machine as described? But if this does sound correct, currently I am looking for a way to set this up straight out of source control? Is that possible, or do I need to have an initial setup phase for all new developers?
Although I can't yet write exactly what you want, Powershell will do what you want. Here's a tutorial for creating web sites and app pools.
http://learn.iis.net/page.aspx/433/powershell-snap-in-creating-web-sites-web-applications-virtual-directories-and-application-pools/
What I would suggest is setting up the full environment on a computer then making a boot disk to return to that environment. Then run that boot disk on another computer (note: must be of the same type) which you want the environment to be on.
If it must work for different computers, and different operating systems, then the complexity of allowing for the environment to all be done at once will become greater than just doing it yourself unless you are setting up environments as frequently as daily. If that is the case, then perhaps you could make a custom installation program to do that which I am not very familiar with off the top of my head.
I've seen several posts about different auto-update frameworks for Window/.NET including:
WinSparkle
NetSparkle
Seven Update
Google Omaha
LimeLM
SparkleDotNET
I was interested in the main differences between these auto-update frameworks, as to why one would choose one over the other.
I am also interested in how secure all of them are. I know for most of them, you must use a hosted XML file to have your app update manifests. How does one make it secure so that a person that hasn't purchased your application, or doesn't use your application simply can't go to your hosted site and download your binaries?
There is another solution called Applife.
http://www.kineticjump.com/update/
Regarding securing the download.
What you could do is secure the download behind an Forefront server.
This server could then authenticate using Active Directory.
If you are an enterprise or a startup wishing to scale, then Omaha is the most powerful solution. Otherwise, your choice will be affected by personal preference and the language in which your main application is written. If you are using C# and want silent updates, then Squirrel might be a good fit. If you are using .NET and want graphical updates, then pick AutoUpdater.NET or the commercial wyUpdate. Finally, if you are not using .NET but still want graphical updates then WinSparkle may be your best choice.
Taken from this article.
Regarding your question of how secure they are in terms of preventing people from obtaining a new version to which they may not be entitled: This needs to be implemented on the server side. You could for instance use a signed S3 URL to only make the download link available when an eligible user checks for an update.
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?