Short Version:
I have 7 SSISDeploymentManifest files I need to run. Is there a way to alter the SSISDeploymentManifiest file to per-populate Installation value?
Rant Version
At first running 7 deployments did not seem like much of a problem. But the part of the process where you "Select Installation Folder" for package dependencies is horribly designed.
First, you have to enter a network path here if you are not running from the server you will install to. This is because the dialog box makes sure path you enter a valid path... on the local machine you run the manifest from. But when the package is run it will need to also work for the server. (dumb huh?))
The next problem with this screen is that the field is read only. So I cannot just specify the path directly.
Second, the dialog box to "browse" won't let me enter a path.
So... I have to browse my entire network (from home, over a vpn). That takes a long time.
Is there a way to alter the SSISDeploymentManifiest file to pre-populate this value?
No, dtsinstall doesn't accept any command line arguments, pity. My first approach to this was to write a heavy, command line application that made repeated calls to dtutil to get things done. I never finished it but if you want to peek, it's on codeplex
What I do like and prefer is a PowerShell script that handles my SSIS deployments now. Even if PowerShell isn't your cup of tea, the concepts should apply to whatever .NET language you might want to use to handle it.
Attractive features of it are that it will create the folders in SQL Server for you and correctly deploy those packages into said folders. The other nice thing that might be of assistance to you is that if all the 7 deploys are in a common folder structure, the script walks the folder structure looking for manifests and deploys all the packages per manifest so you could conceivably deploy all with a single mouse click.
Related
I was able to split the database and used packaging solution to distribute the front-end. I tested it the exe file and it worked fine. Now I am updating the forms and I cannot figure out a way of updating just the front-end (backend is on the server) wihtout going through the new installation of the new package. I did create the template file while going through the process of packaging the database.
I found this website but was afraid the unzip the file. Have any of you use this tool?
http://www.btabdevelopment.com/ts/freetools
Thank you
Some existing tools
Here is a list of deployment tools for Access front ends:
Auto FE Updater from Tony Toews (probably the best, but commercial)
Application Starter from Peter's Software
Front End Updater Utility, from Roger's Access Library
AutoUpdater, from the UtterAccess archives
The one you listed could also help.
More information on deployment
The issue is that there is no single way to update an Access application.
As you discovered, the packaging tools are nice, but they don't really take care of the most important, and complex, part of deploying software: how do you update an existing installation?
Access doesn't have a good story here, so there are many custom solutions, each with its flaws and advantages.
You were right that in any case, you must separate the backend database, containing only the tables, from the front-end, containing the code, forms and reports.
The front-end must be deployed to each user: the rule being that a front-end is meant to be used by a single user only.
What's in a good updater
So, what are the characteristics that you want in a good update story:
User should not have to do anything: you want the user to get the new version of the front-end as soon as it is made available, automatically.
This could mean that your front-end could check if there is a new version available on a remote folder before it allows the user to login or star any work.
If a version is available, it is then fetched and deployed.
Sometimes, because your development environment may be different from the user's environment (different server names, different shared folders, etc), you may also need to re-link the tables in the front-end to the correct path of the back-end after deployment.
What I am using for my deployments
For a few years now, I have perfected my own system that works without a stitch.
Instead of launching the application directly, when the user click the application icon, a small launcher application is started.
The launcher I use is a simple Click-Once application (so it can auto-update) written in .Net.
The launcher is responsible for ensuring that the main application is only running once, and also for checking and deploying new versions (or downgrading them) when updates are made available.
Updates are simply packaged into zip files that contain all the files necessary for a new update.
The name of the file contains the version number, like myAppFE-2013-08-01.zip so that sorting the list of clients packages by name would make it easy to pick the most up-to-date package.
All these front-end packages are stored on a shared folder on a server, for instance if my backend database is in \\myServer\myApp\DB, the front-end packages could be kept in \\myServer\myApp\FE.
When the launcher detects that a new package is available, it deletes the existing folder of the front-end on the user's machine and unzip the new package there instead.
Once the launcher has finished its tasks, it just launches the application frontend.
When the application front-end is started for the first time, it can do more checks to re-link tables if they point to the wrong location.
Notes
An alternative for detecting a new package would be to keep a small text file on the server that would contain the filename of the most current package.
Whenever a frontend is started it could check if the package name it is running is the same as the package name listed in the file. If not, then an upgrade/downgrade is necessary.
One of the advantages of this solution is that once the Access Runtime is installed, users can run in normal user session on the machine, without ever requiring administrator rights: the click-once launcher doesn't require any admin rights and if you deploy your access front-end under the user's %APPDATA% folder, you do not need elevated rights to update your front-end at all.
The first time you deploy, your launcher should also be responsible for registering the location of front-end folder as a Trusted Location so that Access allows it to run without VBA/Macros being disabled.
These are just a set of registry keys you can easily add under HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Access\Security\Trusted Locations\ (the exact registry key depends on your version of Office and whether you are on a 32 bit or 64 bit system).
I would like a way for individual users to send a repo path to a hudson server and have the server start a build of that repo. I don't want to leave behind a trail of dynamically created job configuration. I'd like to start multiple simultaneous instances of the same job. Obviously this requires that the workspaces different for the different instances. I believe this isn't possible using any of the current extensions. I'm open to different approaches to what I'm trying to accomplish.
I just want the hudson server to be able to receive requests for builds from outside sources, and start them as long as there are free executors. I want the build configuration to be the same for all the builds except the location of the repo. I don't want to have dozens of identical jobs sitting around with automatically generated names.
Is there anyone out there using Hudson or Jenkins for something like this? How do you set it up? I guess with enough scripting I could dynamically create the necessary job configuration through the CLI API from a script, and then destroy it when it's done. But I want to keep the artifacts around, so destroying the job when it's done running is an issue. I really don't want to write and maintain my own extension.
This should be pretty straightforward to do with Jenkins without requiring any plugins, though it depends on the type of SCM that you use.
It's worth upgrading from Hudson in any case; there have certainly been improvements to the features required to support your use case in the many releases since becoming Jenkins.
You want to pass the repo path as a parameter to your build, so you should select the "This build is parameterized" option in the build config. There you can add a string parameter called REPO_PATH or similar.
Next, where you specify where code is checked-out from, replace the path with ${REPO_PATH}.
If you are checking out the code — or otherwise need access to the repo path — from a script, the variable will automatically be added to your environment, so you can refer to ${REPO_PATH} from your shell script or Ant file.
At this point, when pressing Build Now, you will be prompted to enter a repo path before the build will start. As mentioned in the wiki page above, you can call the buildWithParameters URL to start a build directly with the desired parameter, e.g. http://server/job/myjob/buildWithParameters?REPO_PATH=foo
Finally, if you want builds to execute concurrently, Jenkins can manage this for you by creating temporary workspaces for concurrent builds. Just enable the option
"Execute concurrent builds if necessary" in your job config.
The artifacts will be available, the same as any other Jenkins build. Though probably you want to manage how many recent artifacts are kept; this can be done by checking "Discard Old Builds", and then under Advanced…, you can select enter a value for "Max # of builds to keep with artifacts".
I have a front-end Access 2007 apllication which talks to MySql server.
I want to have a feature where the application on the user's computer can detect that there is a new version on the network (which is not difficult) and download the latest version to the local drive and launch it.
Does anybody has any knowledge or exprience how this can be done?
Thanks
Do you actually need to find out if there is a newer version?
We have a similar setup as well, and we just copy the frontend and all related files every time someone starts the application.
Our users don't start Access or the frontend itself. They actually start a batch file which looks something like this:
#echo off
xcopy x:\soft\frontend.mde c:\app\ /Y
c:\app\frontend.mde
When we started writing our app, we thought about auto-updating as well and decided that just copying everything everytime is enough.
We have enough bandwidth, so the copying doesn't create any performance problems (with about 200 users).
Plus, it makes some things easier for me as a developer when I can be sure that each time the application is started, the frontend is overwritten anyway.
I don't have to care about auto-compacting the frontend when it's closed (and users complaining that closing the app takes too long...), and I don't have to deal with corrupted frontends after crashes.
#Lumis - concerning the custom icon:
Ok, maybe I should have made this more clear. There is only one batch file, and it's in the same network folder as the frontend.
The users just have links on their desktops which all point to the same batch file in the network folder.
This means that:
future changes to the batch file are easy, because it's only one single
file in one central place
we can change the icon, because
what the user sees is a normal Windows link
(By the way, we did not change the icon. Our app is for internal use only, and I'm working in a manufacturing company, which means that all but very few users are absolutely non-technical and couldn't care less about the icon, as long as it's the same on all machines and they know how it looks like so they can find it quickly on their desktop...)
Tony Toews has one: Access Auto FE Updater
It appears to be free, but I'm not 100% sure.
Lumis's option is solid, however if you want to check the version and only copy the database when their is a new version, have a 'Version' field in a back end table, and a 'Version' constant in a front end module. Keep these in sync with each new production release. Compare the table version against the version in the module when the main form of the front end database opens.
If they don't match, have the database close, but have the database call a batch file as the last bit of code to run as it's closing. The database should finish closing before the batch file begins it's copy process. If needed, place a minor delay in the batch file code just to be sure there are no file locking issues.
We have a .NET Jenkins installation that builds a few .NET apps. These apps include a bunch of *.exe and *.exe.config files. Right now, I save the app as a zipfile containing all of the *.exe, the required DLLs and *.xml files, and the default *.exe.config files. The default *.exe.config get their value from what is in the Subversion repository and is tuned for the production environment.
The *.exe.config files contain the database name, the database server, the name of the server, etc. These are correct for the production environment, but not for UAT, QA, or developer testing.
What I'd like to do is have some sort of post-build task where a user can specify the particular build, and the values for those particular parameters that vary from environment to environment. If I got that, I could run an Nant or Ant task that unzips the zipfile, munges the *.exe.config file and either deploy it (my ultimate goal), or at least zip that up and put it somewhere the user can access it.
I know there's a parameterized build, and I know there are batch tasks, but I need a combination of the two. Is that possible?
It's not as elegant, but I think you can implement what you want as a separate build. You need:
A Parameterized Build (which you know about)
A way to access artifacts from another build
Given these pieces, you should be able to create a Parameterized Build that does exactly what you describe: grabs the build artifact, munges the configuration and provides it somewhere for the user. Of course the devil is in the details, e.g. it may be tricky to make it easy for a user to "select the right build".
Update (now that I've learned about Batch Tasks - thanks!): I don't see a way to parameterize the batch task like you asked. I'm guessing that the combination of variables make it prohibitive to define a bunch of different batch tasks. You could define a couple of batch tasks for common release and testing configurations and also provide the "munger" program for more user-specific configuration.
We have a lot of products that are saving their "states" on the registry.
What is the best practice on saving program states? What are the advantages/disadvantages of saving program states as a registry entry or saving program states to a flat file such as XML?
Thanks!
The obvious awswer would be that storing those states in a normal file, makes it easier for users to backup/restore the state manually.
Also consider that the registry has some keys that are special for each user in the system.
I think registry is the best option to store user-specific information that can be discarded and recovered easily (eg, the last username used to login). Other data should be in a settings file that can be backed-up.
For years programmers had their app settings stored in config files. Then the times changed, and for years they used the registry instead - many of them used it badly, and it caused issues when Vista and its UAC came on the scene.
Nowadays, especially in the .Net world, Windows developers are moving back to storing stuff in config files again. Personally i think that is the best way, if you need to move your app to another machine, or reinstall your OS, all you have to make sure you do is save your config file to retain your settings.
There are things that you may still want to store in the registry though, such as (encrypted) licencing info. For everything else, config files are good. Do pay attention to UAC and file virtualisation though, so that you don't run in to trouble further down the track.
Personally I'd go for the flat file.
(I am assuming that "registry" means windows registry?)
A flat file allows you (or even the user) to inspect and eventually even modify manually the values.
Depending on your situation this could be helpful for debugging, repairing mis-saved data etc.
Unless you thing you want to have the data to be "opaque" and therefore "hard to find/manipulate", the registry offers little in terms of benefits. Maybe it's faster, but if you have lots of state to save you better use an embedded DB instead of a flat file.
I used to follow Redmond doctrines. My programs used .INI files. Then I dutifully switched to the registry - and users started complaining. So, I bucked the trend and switched back to .INI files.
Some want to edit them (good/bad?). Some want to back them up, or transfer to a new machine. Some don't want to lose them if they reinstall windows.
AS a user, I have multiple partitions. Windows/programs/data/swap (and a few others). No programs go onto c:\program files, they all go into the programs partition. No data which I can control goes into c:\user data, it all goes into the data partition (use tweakui power toy, or regedit to change the defaults (but not all programs are well behaved and read the registry for those paths - some just hard code them)).
Bottom line - when Windows gets its panties in a fankle, I do a total re-insatll (approx every three months), and I format the C: drive.
By formatting the windows partition, I get a clean install. My data and programs are safe, though I may need to reinstall a few programs, which is why I go with portable versions where at all possible.
Imo, the registry is the biggest evil ever perpetrated on Windows - a single point of failure.
My advice? Locally stored config files. INI if the user is allowed to edit, serialized or binary format if not.
Or, you could offer a choice ...
Personally I go for a flat file, whether it's an INI file or XML file makes no difference to me. However in my line of work, we've had customers prefer the registry instead due to issues relating to deployment. It depends on who your client base is, and what the person keeping your product working prefers.
I always use regular files because its much easier to develop =)
Simple io vs I don't remember how read/write registry
Simple file copy/paste vs export/import keys for backup/developpement multiple versions of config for testing
Note that all of these advantages also translate into deployment strategies and generic client usage of the configurations
Depends how heavy deployment is. Most of my applications are XCopy-Deployable, that is they don't need an installer and can just be copied/unzipped. So I use .ini Files (using my own INI File Parser as .net has no built in one)
However, if your application needs to be centrally manageable (for example, using Windows Group Policies) or if you have a "heavy" installer anyway, the registry is the prime choice. This is because Applications that are installed normally to to C:\Program Files, and normal users do not have write access to this directory. Sure, there are Alternatives (%APPDATA% or Isolated Storage which has to be used when the Application is a Silverlight app), but you can as well "go with the flow".
Of course, if your application is supposed to run on Mono, you can rule out the Registry anyway and should go Flat Files.