Software Deployment

Kevin118,

The general rule is to not repackage vendor msi's. I agree with this in most cases and in most businesses its fine.

I work for a very large bank with EXTREMELY strict rules about where dll's can be installed and also numerous other rules which dont make exception to vendor msi's So in my case I tend to repackage as a default.

As for siloing......well its pretty simple.

After the capture I totally remove any dll's that conflict with the OS or Office and then move the dll's that the app installed for itself in System32 to the App folder under Program Files\Appname. Then I open the registry file and change any paths to System32 to C:\Program Files\Appname.

Now all the apps dll's are siloed to the app folder. Now run the Conflict Manager to make sure I'm not conflicting with any other apps and its done. The app loads and runs itself completely from the app folder and system32 files are not compromised.

Hi,

I am having a problem with .local isolation. I have successfully isolated APP1 and APP2 as both of them run fine after isolation (but I am yet to do any socialbility testing). However, Conflict Manager shows that the two apps have conflicting registries.

In theory, the apps should first try to load dlls from c:\program files\appname, before checking the registry for paths. Does that mean I can simply ignore those conflicting registries? Or perhaps I should delete them?

Interestingly, if I choose to use merge modules instead of .local isolation, those conflicting registries do not appear in Conflict Manager. I am working with dlls such as comctl, comctl32. mssdfmt and etc.

Thanks in advance.

Hi Alvinator.

Just because ".local" isolation will cause an application to prefer "local" libraries (within the same folder), this does not mean that none of the COM registry entries will be used. The shared copy of the file must still be registered.

You should not blindly delete any registry information. Although deleting the keys might make the conflict disappear, you won't have solved the problem - you're simply hiding it. Although it would be nice if we could simply delete any resources that were causing a conflict!

It is perfectly logical that using merge-modules solves the conflict problem - if both applications use identical components, there should be no conflicts.

Does anyone know where I can find more information about "silo"? I've never heard that term used before. Are there any good web pages or books describing the procedure in detail? How does it work?

It seems that nobody has mentionned the "IsolatedComponent" table? It may be worth noting (for future visitors) that this is the MSI table used for creating ".local" isolated components.

Hi WiseUser,

From what I gather (I work with some ex IBM employees) "silo" is an IBM specific term, though I could be totally wrong on that one ... they are certainly the only people I have heard use it. From what I gather it refers to application isolation.

I asked on various forums about application isolation a while ago, and I got a very useful response from the Installshield vendors which explains the .manifest process very well (in my opinion) and can be found:

http://itninja.com/question/autodesk-land-desk-3-and-tivoli-sd5&mpage=1&key=ࢁ

There.

Hope that helps somewhat.

Rgds

Paul

I do think silo is actually an IBM term as I know they use it to describe there packages. The place I work at has IBM as its outsourcing company. I don't work for them tho.

I thought manifests were only used in dot net apps?

Hi Jim,

I've used it for what I believe are non .NET apps and it appeared to function as designed. I think with .NET you can store the manifest information inside your .exe ... but I'm not sure about that. Also, from what I understand, .manifest is available with Windows XP, and .NET was released after that. The installshield .manifest stuff certainly doesn't mention that it will only work with .net apps.

Rgds

Paul

Hi Paul,

On non dot net apps Wise isolation creates the .local file instead.

I haven't used manifests as yet but its coming my way :)

I believe the new version of Wise PS 5.5 will now take advantage of MSI 3.0 and I'll looking forward to seeing how isolation is now handled in it.

We are currently speaking to Wise concerning some of the testing we have done here because it seems that ActiveX controls (.ocx) are not being isolated correctly and will actually remove the reg keys associated and therefore break any other app that is using it.

Dumb activex.

:)

I'm no manifest expert (I don't proclaim to be an expert in anything really) but I have been thinking a lot about it recently, I wonder to what extent it would allow you to create totally isolated environemnts for applications to run in (almost like running them in virtual sessions) since you can store reg information in the .manifest, and redirect it to files in the local directory. I have been playing with this to no luck (so far), due to the need for the same business area to run the same app with different settings at the same time. If I have a breakthrough I'll let you know.

[EDIT] In installshield, when doing application isolation for Windows XP, it gives you the choice of .local or .manifest. All it says is that XP supports .manifest which is a more complete isolation environment.
[/EDIT]

Its a small IT world in Sydney isn't it? I'm sure people I have worked with have probably worked with you :)

We are currently speaking to Wise concerning some of the testing we have done here because it seems that ActiveX controls (.ocx) are not being isolated correctly and will actually remove the reg keys associated and therefore break any other app that is using it.

Are leaving the "shared" component where it is (maybe "system32"), and using the "IsolatedComponent" table to isolate the component with your "Exe"? You should then ensure that the "msidbComponentAttributesSharedDllRefCount" bit is set for the shared component, and maybe even the "msidbComponentAttributesPermanent" bit (depending what and where).

The question then is whether the "shared" component is being removed on uninstall, or just some of the registration. I believe that Wise SetupCapture doesn't always recognise all of the COM registration as belonging to the correct component. When this happens, you find registry entries belonging to a specific component under a generic component called something like "registry". This generic component usually doesn't have the "msidbComponentAttributesPermanent" bit set.

Its a very small IT world in Sydney and especially in packaging and there is a real need for some new blood because of all the major companies doing rollouts now.

I'm actually working in a large team now and some of crew I have worked with 5 or 6 years ago for different companies.

ORIGINAL: MSIMaker

Its a very small IT world in Sydney and especially in packaging and there is a real need for some new blood because of all the major companies doing rollouts now.


That's because Australian contract rates stink! Most decent Australian (and Kiwi) packagers are working in London.

Although cheaper than London, Sydney's not the cheapest place to live either.

ORIGINAL: WiseUser

ORIGINAL: MSIMaker

Its a very small IT world in Sydney and especially in packaging and there is a real need for some new blood because of all the major companies doing rollouts now.


That's because Australian contract rates stink! Most decent Australian (and Kiwi) packagers are working in London.

Although cheaper than London, Sydney's not the cheapest place to live either.



Hehehe WiseUser, no I think its because all the good ones from the UK come here to drink our beer, enjoy our weather, and chat up the women. Its an unofficial exchange system :) Contract rates are on the rise here again, and though obviously after currency conversion they don't quite match up, if you take into account standard of living etc then it works out well in my opinion. I also think its not just the good ones that go, I know quite a few cowboy packagers that I used to work with who have gone over there and gotten positions quite easily. The UK is welcome to pay them as much as they like to take them out of my hands.

Hi Plangton.

Don't get me started on your "beer"! [:D]

Women, weather, steaks, and wine I'll agree with - but not beer!

There's a lot of cowboys everywhere at the moment!

From personal experience, you're still way better off financially in Europe.

Let's just say that drinking a nice cold beer in the warm and sunny beer garden at the Newport Arms hotel right next to the Pittwater marina while watching the scantily clad eye candy mingle around on a beautiful Sunday afternoon in the sun appeals to me far more than drinking warm beer huddled around the hearth in stockings and scarf :)

Gotta love this country especially in summer :)

ORIGINAL: MSIMaker

Let's just say that drinking a nice cold beer in the warm and sunny beer garden at the Newport Arms hotel right next to the Pittwater marina while watching the scantily clad eye candy mingle around on a beautiful Sunday afternoon in the sun appeals to me far more than drinking warm beer huddled around the hearth in stockings and scarf :)

Gotta love this country especially in summer :)


This thread is way off topic, but can I feel a www.appdeploy.com Sydney chapter drinking session coming on? :) Could it get any geekier?

Hi Msi maker,

you have said that you re-package vendormsi because of strict rules of that banking company.......like dll should get installed in the right location.I feel that can also be achieved by making changes in the transforms.......

Its my thought

Let me know if i am wrong...........I have tried that few times

Nagaraj