Ron Allen
chizotz at mchsi.com
Fri Apr 27 11:29:34 CDT 2007
John, It can be as easy as copying the new .NET exe file to the user computers, overwriting the old version. This is how I handle upgrades and bug fixes in my shop, and it works fine. I was also amazed at the sparse information available on deployment. I couldn't find anything substantial or truly useful when I was exploring these issues some time back. Finally, I reasoned that all an installer really does is: *copy the needed files to the target machine *register any library files as needed *set up any necessary directory structures *add any necessary registry entries *create icons The installer built in to VS is not particularly intuitive to use if you want to do anything fancy, even though it appears to have a fair amount of power if you know how to harness it; there is very little useful documentation on how to anything that I have been able to find. But what I have found is that once the initial install is done, unless you need to add additional library files that must be registered on the user system, upgrades can be done by simply copying the new .exe file over the old version on the user machine. One caveat, if you want to upgrade in this manner you can not use the built-in auto-increment versioning because the internal version of the .exe file is registered on the system and replacing the file with one that has a different internal version will cause it to fail. I work in a relatively small shop, with responsibility for 19 users and direct access to all machines. The path of least resistance for me is to stick the new version out on a common location on one of the servers, then go to each workstation and simply copy the new version over the old. However, in the past I have used a DOS batch file with a shortcut on each desktop, and notified everyone by email to run the upgrade; that also works, if your users are responsible enough to follow instructions. We've also discussed having upgrades performed on each machine reboot, checking for new versions and copying only if a new version exists; that would work because we mandate that all machines except mine (I occasionally have to remote in) are turned off at night, and my machine is irrelevant because it is the development machine. Don't know if this helped at all, but I guess the real point is that there are many ways to get this accomplished and it needn't be a huge hassle. Ron ps to all you book-writing gurus out there: I'd say that the world is way ready for a good solid and *usable* book on deployment. > Incredibly, application distribution is a subject that is not much in the > news. I googled around trying to find out "the how" and there is not a lot > out there. My books do not even have the word "deployment" in the index. > Simply incredible. > > I work on a computer at my office. I want to install the application on a > server at my client. What do I do? Apparently there is a "project" that > wraps the project that is to be installed that builds an installer (MSA?). > That is fine, except that the installation onto the server may or may not be > the end of the subject. > > Some things may be a server based application, the server actually runs the > application. This would be things like an application that watches an FTP > directory, when files appear they are downloaded to the local hard disk, > unzipped / unencrypted and then the files are imported to the database. > Likewise an application (in fact very likely the SAME application) pulls > data out of the database, encrypts / zips it and uploads it to an FTP > directory somewhere. > > With other things, the movement to the server is just the first step. From > there, the user needs to execute the application, i.e. needs to download the > application to their desktop and run it. If there are changes then somehow > the changes need to be automatically pulled down as well. It could be > something as simple as copying the whole darned directory and all of its > subdirectories but I certainly hope not. Of course if that is not huge then > why not? So far these are little applications, as opposed to the main call > center app which is an Access FE with hundreds of tables, queries, reports, > modules and reports. > > These are applications such as the report generators that create data feeds > to the mainframes. They take a certain amount of setup - selecting product > types and date ranges before clicking the button. > > All of these applications may change on a daily / weekly basis. I am a one > man show for the client so they have a huge list of "things to do" which > include but are not limited to these applets, and of course there are bug > fixes. Each of these things may get a new report this week, a fix to some > specific field today and so forth. Updates are relatively easy with Access > since it is at most a library mda and the fe. > > How do I do all this in vb.net? I need to be able to make changes and push > it out whenever it is ready, quickly and conveniently. And of course I > often times remote in and work local to the machine because it saves the > hassle of the FTP up / down to get things back and forth. > > John W. Colby > Colby Consulting > www.ColbyConsulting.com > > -----Original Message----- > From: dba-vb-bounces at databaseadvisors.com > [mailto:dba-vb-bounces at databaseadvisors.com] On Behalf Of Jim DeMarco > Sent: Friday, April 27, 2007 8:55 AM > To: dba-vb at databaseadvisors.com > Subject: Re: [dba-VB] Deploying .net solutions > > There were certainly security issues in VS 2003 but I'm under the impression > they've been dealt with in 2005 but this is M$ we're talking about. > > > Jim > > -----Original Message----- > From: dba-vb-bounces at databaseadvisors.com > [mailto:dba-vb-bounces at databaseadvisors.com] On Behalf Of JWColby > Sent: Friday, April 27, 2007 8:40 AM > To: dba-vb at databaseadvisors.com > Subject: Re: [dba-VB] Deploying .net solutions > > I read about that on the internet last night, and it looks like it might be > a viable method. I also read that it has some issues, particularly in the > presence of different versions of the .Net framework on the desktop, and > also IIRC something about security issues and what the app is allowed to do. > > John W. Colby > Colby Consulting > www.ColbyConsulting.com > > -----Original Message----- > From: dba-vb-bounces at databaseadvisors.com > [mailto:dba-vb-bounces at databaseadvisors.com] On Behalf Of Jim DeMarco > Sent: Friday, April 27, 2007 8:31 AM > To: dba-vb at databaseadvisors.com > Subject: Re: [dba-VB] Deploying .net solutions > > ClickOnce is the technology I was referring to. > > > Jim > > -----Original Message----- > From: dba-vb-bounces at databaseadvisors.com > [mailto:dba-vb-bounces at databaseadvisors.com] On Behalf Of Jim DeMarco > Sent: Friday, April 27, 2007 8:00 AM > To: dba-vb at databaseadvisors.com > Subject: Re: [dba-VB] Deploying .net solutions > > John, > > If you mean how are you going to get updates to users you should look at > "smart client" applications where the client is aware of changes and > downloads them from a central location before the app starts. I don't have > much experience with it but I expect I will soon as we're moving a major > client/server app to .NET this year. > > > Jim DeMarco > > -----Original Message----- > From: dba-vb-bounces at databaseadvisors.com > [mailto:dba-vb-bounces at databaseadvisors.com] On Behalf Of JWColby > Sent: Thursday, April 26, 2007 10:51 PM > To: 'Access Developers discussion and problem solving'; > dba-vb at databaseadvisors.com > Subject: [dba-VB] Deploying .net solutions > > I have a bunch of processes that are not particularly suited to Access for > one reason or another. These include things like > > * doing what I call "directory watching" and performing some action when a > file appears. > * FTP transfers between local drives and FTP sites > * Building complex data feeds between a database and a remote mainframe > > To take an example, I regularly build data feeds which look like: > > Header Rec > Detail Rec > Detail Rec > Detail Rec > . > . > Trailer Rec > > The header rec has some specific set of data in it such as who it is coming > from, the date of the file etc. > > The detail recs have repetitive data such as payments to clients, payment > dates, from/to dates that the payment is for, the amount, the check number > etc. > > The footer rec has some specific data in it such as the number of checks, > the bank account number that the checks are drawn against etc. > > I have built a report generator in VBA, inside of access, and it works, but > it is really rather patchwork by nature. I have to reference specific libs, > go outside of VBA to handle things like the file system and text streams (in > an object oriented manner) and so forth. There are no threads so a single > error can hang the system, and things that should happen in parallel have to > happen sequentially. > > So, I would like to take one of these systems and move it to .Net. What I > am trying to discover is how .Net systems are (reliably) deployed to the > desktop. Often times these applets are used by more than one person, often > at the same time. At the moment, because they are Access / vba based, I > just do a copy down to the desktop (a single file) and open the mdb. A form > opens and the user goes to work. These applets are under constant > development, literally daily as I finish one report another is started. Bug > fixes are done. > > I assume (but am not sure) that a VB.Net applet would be distributed as > well, downloaded to the desktop and run from there. What is the vehicle for > this distribution? > > John W. Colby > Colby Consulting > www.ColbyConsulting.com > > _______________________________________________ > dba-VB mailing list > dba-VB at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/dba-vb > http://www.databaseadvisors.com > > > _______________________________________________ > dba-VB mailing list > dba-VB at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/dba-vb > http://www.databaseadvisors.com > > > _______________________________________________ > dba-VB mailing list > dba-VB at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/dba-vb > http://www.databaseadvisors.com > > _______________________________________________ > dba-VB mailing list > dba-VB at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/dba-vb > http://www.databaseadvisors.com > > > _______________________________________________ > dba-VB mailing list > dba-VB at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/dba-vb > http://www.databaseadvisors.com > > _______________________________________________ > dba-VB mailing list > dba-VB at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/dba-vb > http://www.databaseadvisors.com >