Install solutions like ClickOnce - deployment

Are there other things out there like ClickOnce, but that use the actual application files?
I am finding the signing and packaging process very difficult to pass off to others.
I have tools than can make an MSI. But the deploy process of ClickOnce is very useful.
Is there something out there that works like ClickOnce but uses an MSI?
NOTE: I need what ever I use to not require the help of my System Admins. They are in a different structure of my company and rolling out my releases via them would delay things too much. (This means that using a Group Policy is not feasible.

Installshield has in their Premier and Professional editions has a feature that will check for updates before each execution, just like a ClickOnce application, which sounds like just what you are asking for. However, the price is not cheap.
http://www.flexerasoftware.com/products/software-installation/installshield-software-installer/tab/features

Related

Using a Script; install a Windows Store App

Requirement: install a Windows Store app without requiring the user to nav to the store and click Install. Perhaps a batch file. Perhaps a Powershell script. Perhaps something else.
This is not a side-load question; this is a public, Windows Store question
Scenario 1: Maybe, my company has a new app in the Store that I want to push it out to every single employee without requiring them to nav to the Store and click Install.
Scenario 2: Maybe, my company has just subscribed to online CRM (or something) and I want to push out the CRM client to every single employee without requiring them to nav to the Store and click Install.
Scenario 3: Maybe, my company is hiring new employees & preparing new computers. In their first-time login script (or something) I want to ensure they have the Apps important to my business - without requiring they nav to the Store and click Install (perhaps several times).
Scenario 4: Maybe, my company is very virtualized, and we provision new VMs all the time. The VM performs fine, but bandwidth is our problem. To streamline the user experience, users logon and watch as the VM prepares itself for them by downloading and installing Windows Store Apps for them.
Please don't pick on the scenarios, I am just trying to give a possible use case.
Complication: I have been told (by people who know this sort of thing) that there is no built-in API to accomplish this. But we are developers. Nobody dares tell us something is impossible. But, if there isn't a built-in API, how could a network administrator or developer on a team solve this problem? I realize this question is somewhat brainstorming. But it gets asked over and over and over and over. I would like to provide a resource for others who might be considering the same scenario.
Hey, perhaps this is easy. Please share.
We have SCCM in our environment and some PS scripts are deployed in C:\Windows\CCM\SignedScripts that may be worth investigating. They are not SCCM specific. The most relevant of the three is "C:\Windows\CCM\SignedScripts\installwindows8app.ps1". The script just passes parameters to Add-AppxPackage though I am not sure how it would get the path to the .appx in the MS store.
You can get the location of installed apps on a model machine with (Get-AppxPackage -Name "*").InstallLocation but then you would need to repackage, store, deploy, and maintain them--not really the solution you were looking for.
Between investigating how SCCM would do it with these scripts and digging in the installed apps, maybe someone runs across something.
Almost 8 years into the future and we are getting closer to an answer!
Recent versions of Windows 10 now come with "winget" and they've added some Microsoft Store support.
It seems hit and miss as to what apps I can install. Using Spotify as an example,
winget search "Spotify"
Probably best to install via id instead though:
winget install 9NCBCSZSJRSB
Since it stops and asks if you want to agree to the terms and conditions, you answer automatically via:
echo Y | winget install 9NCBCSZSJRSB
As one of my references states: "What’s interesting is that if you have the Microsoft Store open at the same time as running winget install, you’ll see the install progress updating in real time in both the command line window and the Store GUI."
There is plenty left to be desired with this answer since most automated installs will probably just run into the error "Verifying/Requesting package acquisition failed: no store account found". But, if you're able to run it as the user, you might have some more luck. I'd love to see this tool get more finished so it can actually accomplish all the scenarios you listed. As Microsoft updates the tool, we could update this answer accordingly.
References and notes:
There's also the unlisted option --scope user or --scope machine found via: https://aka.ms/winget-settings
This page was helpful in my discovering of the tool: https://petri.com/how-to-programmatically-install-microsoft-store-apps-using-windows-package-manager
If you want to change and compile winget on your own, the source is here: https://github.com/microsoft/winget-cli/
Isn't this what Intune is for? http://www.microsoft.com/en-us/server-cloud/products/windows-intune/default.aspx#fbid=CFXRSOlwIM2

How should I create an automated deployment script?

I need to create some way to get a local WAR file deployed on a Linux server. What I have been doing until now is the following process:
Upload WAR using WinSCP.
SSH into server using PuTTY.
Move/Rename/Delete certain files folders to prepare for WAR explosion.
Explode WAR.
Send email notifying users of restart.
Stop Tomcat server.
Use tail to make sure server stopped correctly.
Change symlink to point to exploded WAR.
Start Tomcat.
Use tail to make sure server started correctly.
Send email notifying users of completed restart.
This stuff is all relatively straightforward. And I'm sure there are a million and one different ways to do it. Id like to hear about some options. My first thought was a Bash script. I have very little experience with scripting in general but thought this would be a good way to learn. I would also be interested in doing this with Ruby/Python or something current like this as I have little to no experience with these languages. I think as a young developer, I should definitely get some sort of scripting language under my belt. I may also be interested in some sort of software solution that could do this stuff for me, although I think scripting would be a better way to go for the sake of ease and customizability (I might have just made that word up).
Some actual questions for those that made it this far. What language would you recommend to automate the process I've listed above? Would this be a good opportunity for me to learn Bash/Ruby/Python/something else, or should I simply take the 10 minutes to do this by hand 2-3 times a week? I would think the answer to this is obviously no. Can I automate these things from my computer, or will I need to setup the scripts to run within the Linux server? Is the email something I can automate or am I better off doing that part myself?
More questions will almost certainly come up as I do this so thanks to all in advance.
UPDATE
I should mention, I am using Maven to build the WAR. So if I can do all of this with Maven please let me know.
This might be too heavy duty for your needs, but have you looked at build automation tools such as CruiseControl or Hudson? You might also want to look at Integrity, which is more lightweight and written in Ruby (instead of Java like the other two I mentioned). These tools can do everything you said you needed in your question plus way, way more.
Edit
Since you want this to be more of a learning exercise in scripting languages than a practical solution, here's an idea for you. Instead of manually uploading your WAR each time to your server, set up a Mercurial repository on your server and create a hook (see here, here, and especially here) that executes a Ruby (or ant, or maven) script each time a changeset is pushed from a remote computer (i.e. your local workstation). You would write the script so it does all the action items in your list above. That way, you will get to learn three new things: a distributed version control paradigm, how to customize said tool, and how to write Ruby scripts to interact with your operating system (since your actions are very filesystem heavy).
The most common in my experience is ant, it's worth learning, it's all pretty simple, and very usefull.
You should definately automate it, and you should aim to have it happen in 1 step.
What are you using to build the WAR file itself? There's some advantage to using the same tool for build and deployment. On several projects I've used Ant to build a Java project and deploy it to the servers.

Technologies for centrally storing and publishing perl scripts and "small tools"?

My problem:
There are numerous (>100) tools the development teams use which are "home" written. They are sometimes a perl script, or a "web page", or just something that does a couple of small functions. I need to find a way (as part of my "Middle Manager in charge of tools" job) to collect these into a single catalogue. None of these tools are "productised" in any way.
I need to be able to somehow measure usage of each tool. Uploading or submitting a tool should be a trivial exercise, as should downloading the tool. Must have version management and control.
Is there a technology for centrally storing and publishing these small tools?
Does anyone have experience of such quixotic ventures in other companies?
Supplementary question...
What sort of process checks are appropriate? Do you have a review board for tools going up on the server?
I want to ensure we don't have unintentional consequences from scripts. I also want to ensure that the "Business Critical" set are identified and maintained.
We use a web-accessible front-end to SVN for 'field-developed' scripts, customizations, and small tools.
addition
What I use now is an instance of trac tied to svn on my web server. I don't know if trac handles checking-in code as well - the version I'm running does not.
The front-end I referred to previously was in use where I used to work, and I don't know what it was exactly.

Deployment in an agile environment

In the past my development team we have mostly done waterfall development against an existing application and deployments were only really done towards the end of a release which would normally result in TEST, UAT, PROD releases normally only consisting of three to five releases in a two month cycle.
A release was an MSI installer, deployed via Group Policy.
We have now moved to a more agile methodology and require releases at least once per day for testing, some times more often.
The application is a VB6 app and the MSI was taking care of COM registrations for us, users do not have elevated privileges on their machines.
Does anyone have any better solutions for rapid deployment?
We have considered batch/scripted installs of the MSI, or doing COM registrations per file, both using CPAU for elevated privileges, and ClickOnce. Neither of these have been tested yet.
Edit: Thanks for suggestions.
To clarify, my pain point is the MSI build / deployment process takes a long time can take up to two hours to get the new build on to the testers desktops. The testers do not admin rights on their machine (and will not get them) so I am looking for a better solution.
I have played around with ClickOnce, using a dot net wrapper which starts up the application and has all the OCX/DLL vb6 assemblies as isolated dependencies, but this is having issues finding all the assemblies when it starts up, or messages to that effect.
CruiseControl and Nant are probably your best bet for builds with flexible output. But Rapid Deployment?
My concern is that you are looking at the daily builds in the wrong way. The dailies do NOT need to be widely deployed. In fact, QA and Development are the only ones who should care about the builds on a day to day basis. EVen then, the devs shouldn't be out of sync ;).
The customer team should only recieve builds at the end of a iteration. That is where you show them what you have done and they provide feedback and you move forward from there. Giving them daily builds could cause a vicious thrashing that would kill your velocity.
All that being said, a nice deployment package might be good for QA. But again, it depends on how in step they are with your development iterations. My experience, right or wrong, is that QA is one iteration back testing the deliverables from the last iteration. From that point of view, they should be testing with the last "stable" release as well.
Is this something you can do in a virtual machine? You could securely give your testers admin rights on the virtualized system and most virtualization software has some form of versioning so you can roll back to a "good" state if something goes wrong. I've found it to be very useful for testing.
I'd recommend ClickOnce with the option to update on execution. That way only people using the software receive and install the updates.
You could try registry-free COM. See this other question. ActiveX EXEs still have to be registered though.
EDIT: to clarify, using registry-free COM means the OCX/DLL components you mention don't need to be registered. Nor do any OCX/DLL components they use. You can just copy the whole application directory onto a tester's machine and it will work straightaway.
If I understand your question correctly, you need admin rights to install your product. I see three options:
1) Don't install to the tester's desktops. Get some scratch testing machines (as dmo suggested, VMWare might help) that you can safely give them admin rights to. This may mean giving them a test domain and their own group policy to edit.
2) Build a variant that doesn't require MSI installation, and can be executed directly. Obviously your testers would not be testing the deployment and installation process with this variant, but they could perform other tests of the product's functionality. I don't know if this is possible with your product; it would certainly be work.
3) Take your agile medicine: "[prefer] responding to change over following a plan". That is, if denying admin rights to your testers is interfering with their ability to do their jobs efficiently, then challenge the organization to give them admin rights. (from experience, this will mean shifting to #1, but it might be the best way to make the case). If they are expected to test the product, how can they not even be allowed to install it in the same way a customer would?
If the MSI deployment is taking velocity out of agile testing, then you should test MSI deployment less regularly.
Use XCOPY deployment wherever possible, using .local for COM components. This can be a problem with third party components. As third party components are pretty stable, you should be able to build a custom MSI for these, install them once and be done with it.
You should try an automated build/deploy process or script that you can manually run. Try Teamcity or CruiseControl. Good luck!
I'm not sure just precisely what your pain point is.
You specifically mention registration of VB6 COM objects. Does the installer sometimes fail because of that?
Is it that the installer works but people don't know to install the new build so they are more often than not reporting bugs on an old build?
If the former, then I suspect the problem to be that VB6 was very likely to play fruit basket turnover with the GUIDs when rebuilding the solution. Try recreating your public interfaces in MIDL and have your VB6 classes implement those interfaces.
If the later, then try Microsoft's SMS product. No, it has nothing to do with cell phones. If all the user's aren't on the same domain, then you will have to build an "auto update" feature into your product. Here is a third party offering that I've heard of but never used.
I'm using SetupBuilder (http://setupbuilder.com/products_setupbuilder_pro.htm) for all my builds. Very extensible. Excellent support.
Not sure exactly if it fits your needs, but this kind of post on the forums, "Installing as a limited account user (non-admin) on XP" (http://www.lindersoft.com/forums/showthread.php?t=11891&highlight=admin+rights), makes me think it might be.

Tools to help a small shop score higher on the "Joel Test"

Questions #1 through #4 on the Joel Test in my opinion are all about the development tools being used and the support system in place for developers:
Do you use source control?
Can you make a build in one step?
Do you make daily builds?
Do you have a bug database?
I'm just curious what free/cheap (but good) tools exist for the small development shops that don't have large bank accounts to use to achieve a positive answer on these questions.
For source control I know Subversion is a great solution, and if you are a one man shop you could even use SourceGear's Vault.
I use NAnt for my larger projects, but have yet to set up a script to build my installers as well as running the obfusication tools all as a single step. Any other suggestions?
If you can answer yes to the building in a single step, I think creating daily builds would be easy, but what tools would you recommend for automating those daily builds?
For a one or two man team, it's already been discussed on SO that you can use FogBugz On Demand, but what other bug tracking solutions exist for small teams?
source control: Subversion or Mercurial or Git
build automation: NAnt, MSBuild, Rake, Maven
continuous integration: CruiseControl.NET or Continuum or Jenkins
issue tracking: Trac, Bugzilla, Gemini (if it must be .NET and free-ish)
Don't forget automated testing with NUnit, Fit, and WatiN.
1) Subversion
2) Ant / Maven
3) Continuum
4) Bugzilla / Trac
My preferred stack:
1) Subversion. I'm intrigued about distributed source control but haven't had chance to try any in anger yet. For a centralized solution svn is rock solid.
2) Ant. Maven is a joy to use when it's working but as an old ant hacker I find maven to be hard to follow once things go wrong.
3) Hudson. Not been mentioned so far but definitely worth investigating. Incredibly usable and actively maintained tool. PreviousLy we paid for Anthill Pro which seemed flakey and was painful to fix each time it screwed up.
4) We pay for jira. Not cheap but much more usable than the open source options we looked at and very flexible too.
My engineering stack:
Git (I love GitHub, but Git doesn't require a hosted solution)
Rake
CruiseControl.rb
FogBugz
No doubt these choices are influenced by my development stack, which most often includes Ruby, Rails, SQLite, Firefox, and OSX.
You may want to look at an existing question of mine for finding an alternative to Team System. There are plenty of recommendations in there also.
Git
Make
Cron
Trac
I'm a man of few syllables ;-)
Be sure to use some kind of version control where developers can easily create private branches willy-nilly, then take their private branch and squeeze it into a single commit on the main branch. That way, individual developers---as opposed to the organization---can get the benefits of version control without polluting anyone else's code (and slowing down their work) with broken commits.
This feature is what I like about git. I think it's only really present in distributed version control systems; using a DVCS doesn't mean you actually have to do distributed development, though.
Regarding one-step building, make is the default build tool and it works quite well for most tasks. I'd go with that unless you have a good reason not to.
You want daily builds, put the build command in your cron.daily. Set up a procmail hook to handle the mail from cron if need be.
For bug tracking, use $(apt-cache search bug tracking). Basically, as long as it says "bug tracker" on the box and you know other people are using it, it's probably going to work fine. Among the regulars are bugzilla, mantis and trac.
I don't have any tools to suggest, but I do have a suggestion about the daily builds. I always answer yes to that question, even though we don't have daily builds. Instead, we do a build every time someone does a commit. We thereby catch any problems almost immediately. If any of our projects ever has enough LOC that building takes more than trivial time, doing this will also gracefully degrade in the direction of a daily build.
A good issue tracker that was relatively inexpensive was axoSoft OnTime. I used it for years before getting MS TFS.
Nant and CruiseControl are staples of my environment.
I don't think you really need obfuscation on .Net any more (see another response)
I wouldn't consider Vault, SVN is really the market leader at the moment (and free). Git is looking pretty promising but currently is command line only with a steep learning curve.
MSBuild beats NAnt for .Net 2 or 3.5
CC.Net is excellent.
*4) Redmine
I recommend Bitnami for testing out different stacks. It's got Trac, Redmine, and Subversion, as well as several other unrelated ones.
Check out these articles on Continuous Integration using MSBuild, CruiseControl.NET, FxCop, NUnit, NCover and Subversion...
From the software development trenches
I'm currently using SVN but I've generally had a lot or problem with checkouts to a network drive on a dev server. There tend to be locking issues that require a lot of fishing around to fix. It may be that using the WebDav access method, would ease some of these problems, but I haven't experimented yet.
Any of Bugzilla, Trac or Fogbugz will help you with your bug tracking, and each offer an export feature, so you can always change your mind later on. Also, if you can get your team to fully buy in, time management software can also be handy for post-mortems, etc (if everyone is motivated to fully participate.
For build automation and continuous integration take a look at TeamCity from Jetbrains.
It has a lot of features and is really a breeze to set up and use.
If you use Visual Studio 2005/2008 it will build your solution directly without the need for extra scripts (if a build is all you want.)
It will also execute your unit tests and gather stats on build success, unit test execution times, etc, etc.
Best of all: The Pro edition is free for teams with up to 20 users and 3 build agents.
source control: cvs
build gnu make
cron job that calls bash scripts
bugzilla