开发者

Side by Side manifests, hot or falling from grace? [closed]

开发者 https://www.devze.com 2023-02-11 21:14 出处:网络
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references,or expertise, but this question will likely solicit debate, a
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. Closed 9 years ago.

We have run in some .dll hell problems for our clients lately, so I was wondering if SxS installations of t开发者_开发百科he requiered .dll's and .ocx's is a good idea. I read about it and succeeded in deploying our application when at least some of its dependencies were catered for through a manifest, but is it still the recommended way of deploying, or is it a fad from the last few years and now gradually being abandoned?


I don't see why it would be a fad. The concern in VB6 is that there was never a tools update to support it directly, though VB6 SP6 improved support and XP SP2 provided a more complete implementation.

We use it all the time here, though we have found that certain 3rd party controls are not properly written and can't work with it. Lots of the vbAccelerator stuff seems to be "broken" in such a way for example.

It's a rare case we don't deploy using reg-free COM now, even when we wrap it all up in an MSI package. Being isolated from other products' poor installers (the source of much DLL Hell) is a big plus, and Windows is getting better about defending itself in terms of system components which helps a lot in itself.

The trick is finding good tools support. I've never had the patience to work through applying Microsoft's sketchy support via SDK tools but I think others have. There is at least one commercial product for this kind of thing. We use our own tools developed in-house.

Fad? We consider it competitive advantage. It sure makes it easier to produce portable software in VB6 too! Unlike some of the runtime library loading and hacking toolkits we've seen from a German source you don't have to add a lot of fiddley coding to your programs either. Just plain old VB6 programs work fine.

The other thing it enables is per-user deployment, making it easy to create MSI packages that install for a user without elevation rights. We're not primarily about producing stealthware but customers sometimes face some high walls within their organization and this lets them install the products we offer and get on with their jobs. Since we aren't touching the registry or protected filesystem areas the negative feedback from admin types has been almost zero. Windows 7 enhanced this:

Authoring a single package for Per-User or Per-Machine Installation context in Windows 7

The same technique works on Vista though you don't get single-package functionality. Building the applications isolated makes the process even easier.

Of course SxS means a lot more than reg-free COM and isolation, but in VB6 terms that's probably what you were talking about. DotNet uses it, the OS uses it. I'm not sure why it might look lke a "fad." Perhaps many people have gone quiet on the subject through frustration with the tools, a move from VB6 to something else, or because the economy is very competitive right now.


I have experimented with SxS in the past but stopped using it after encountering issues on a certain percentage of Windows XP machines where the application was supposed to run.

0

精彩评论

暂无评论...
验证码 换一张
取 消

关注公众号