Miscellaneous

totoymola,

I saw you posted this several days ago and that no one has replied. I am compelled to reply because this is SO similar to the way I started off. I had the tools, but very little knowledge.

Unfortunately, there is no simple magic path to learning repackaging. It is a very specialized skill, and a quality package results from doing many little things well - not one or two things.

Do not get discouraged, though. The fact that you are here at AppDeploy shows you are doing what you need to do to learn - although you may not fully realize it yet.

I am not even close to the most knowlegable packager on this forum, but I know 1000 times what I did two years ago. I would say that 90% or more of what I know comes from: [ 1.) needing to figure out how to do something 2.) doing something bad out of ignorance and having it blow up in my face ] and then coming to sites like this to learn what I needed to do. Once upon a time I repackaged a release of MDAC and pushed it out to a few machines. Ooops. Guess it was time to learn about Windows Protected Files and Merge Modules.

So first I would say: keep coming here and reading as many posts as you can. Pay attention to the posts from super members, especially bkelly, MSImaker, cdupuis, WiseUser, VikingLoki, JMcFayden, kkaminsk, and eWall. They really know their stuff, and they will be invaluable to you learning about things ahead of time, instead of when you are crunched for time on a package. No offense to any members I did not mention; there are definitely others. As you read more posts, you will know who has the detailed knowledge. I read much more than I post, for certain.

Second, look for other sites that can help you, and read them as well. Some I would suggest are: the Wise Package Studio and InstallShield user forums, Desktop Engineer (courtesy of Darwin Sanoy), and InstallSite, and eWall. As you visit these sites, note the participants that you recognize from AppDeploy.

Last, I would put together a list of things for online / self study using these site or whatever you can find. In loose order, I would suggest:

- building good exclusion lists; using clean machines to build clean packages
- turning on verbose Windows Installer logging
- per user vs. per machine installs / installing with elevated privileges
- use of merge modules and dealing with Windows Protected files
- pick up a good book on the registry
- using secedit, xcalcs, etc, to edit permissions using custom actions (or learn some robust technique for customizing permissions)
- understanding self repair and HKCU entries
- application isolation and “.dll hell”

There is more, but this knowledge can get you through quite a few more difficult packages, and produce quality results.

Keep on reading and posting


Craig --<>.

what the other guy said - read, read, and more practice.

altiris.com/support/forum has a lot of knowledge.

Also if it doesn't put you to sleep, the Windows installer SDK and wise (or installshield) help files provide good reading.

If it was easy, anybody could do it! Best of luck
Owen

Hi Totoymola,

It is also a good idea to try and familiarize yourself with the deployment tools, these play a big part on what modifications you will or won't have to make to certain packages function beyond the install. Another valuable skill is to know the Windows file system and registry inside and out, learn file security, learn what causes files to either inherit or not inherit permissions, this may be a better area to start as learning these are not only easier than learning packaging (or repackaging), but they will help you better understand the 'art' of packaging applications. I am not sure what you want to specialize in, but it is a good idea to have a basic knowledge of all deployment, repackaging and editing applications, that way you can specialize if needed by an employer.

Craig, would you consider this information as valid for those of us involved with amost exclusively the distribution of software? The software I get is already in some packaged format (setup.exe and msi's), and I have no role in how they are made. Most come from outside vendors who are loathe to repackage anything for JUST us (I work for a hospital). But I have occassion here recently to need the packages in a different format. For instance, the ORMIS 7.33 package wants to install MDAC, but I don't know how to get it to not do that part. It seems built into the msi, and everyone here seems to think something called transforms are what I need to get that to work. Just curious as to the differences in those two situations (packaging vs deploying). Is it possible to change these packages if you, as a techie, are not involved in their creation?

Thanks for your time,

John

John,

I guess I would have to say that the information cdupuis and I provided is going to be most valid for the network/desktop administrator who is going to:

1. Commit him/herself to an extended learning process and to a standardized deployment process. Example: On more than one occassion I have had a team member approach me and say something like, "Could you teach me how to repackage into .msi this week". When they find out that I need them to dedicate several months of learning, practicing and submitting work for review before I will allow them to start contributing packages for real time deployment, they quickly lose interest.

2. Commit him/herself to a standardized method of deploying and managing software and the desktop environment. This ties into what I stated in #1 above. In other words, repackaging software just to tweak things here and there, or just to make it more convenient to deploy software is not really what repackaging is all about. This kind of approach can lead to not investing the time and effort needed to create stable, quality packages. As I alluded to in my first post in this thread, one can EASILY trash systems out of ignorance if one doesn't know exactly what one is doing.

To address your question about ORMIS, I don't believe a transform is going to get you where you need to go. I take it the install does not inform you it is going to install MDAC or give you an option? If that is the case, you would need an .msi editing tool like Wise Package Studio, InstallShield Admin Studio, etc., to edit the .msi and remove MDAC. MDAC is probably in there as a merge module (a.k.a. "redistributable"). The problem with removing it is that you will also remove files, and ORMIS more than likely will not run without them. I could go further into info about MDAC and merge modules here, but it gets very involved. It is almost a subdiscipline itself within the discipline of repackaging.

There is another forum member here whose posts you may want to read up on, because he is also the in healthcare industry: brenthunter2005. You may get some good perspectives from what he contributes here at AppDeploy.


Craig --<>.

Wow! It's been a while since my last visit to this thread. I thought no one is going to reply. But I'm wrong!

Thanks guys for the advices and encouragement, especially to craig16229, aogilmor and cdupuis. It helps a lot. Yes I know the only way to learn without formal education is throuhg reading. That's what I'm doing. But I can't deny the fact that it's really difficult. Especially for a nursing student like me who has hundreds of reading priorities. I'm living one day at a time. I absorb as much information that I can for today.

I have tools here as my toys. Most of them are demo and shareware.

I am compelled to reply because this is SO similar to the way I started off. I had the tools, but very little knowledge.
This gives me hope. [:)]

Also if it doesn't put you to sleep, the Windows installer SDK and wise (or installshield) help files provide good reading.
Yeah I have some of them. But reading them is not a joke. [:D]

I am not sure what you want to specialize in, but it is a good idea to have a basic knowledge of all deployment, repackaging and editing applications, that way you can specialize if needed by an employer.
That's all I'm striving to learn for now, the basic.

Again, thank you for your replies.

Take care.

Carlo