0

My group has created a .NET assembly and it works great in our VB2010 projects. We have also made some of the functions available to VB6 and thus have created a COM Callable Wrapper. We have tested this also and that works great. Our last step is to determine how to deploy to users within our company. We know what files to deploy and how to register them. I have been scouring MSDN and other sources as to WHERE to deploy them to?

Currently we deploy the wrapper DLL, TLB, and Interop DLL to {pf}\MyLib. Are there any best practices of where to deploy a CCW? I am thinking since it's a COM object it has to be registered and should go in {sys}. Any references I can look at to make a decision would be appreciated.

sinDizzy
  • 1,300
  • 7
  • 28
  • 60
  • 2
    It doesn't matter where you put. That's the point of registering it, that writes a registry key that says where you put it. Don't use "sys", c:\windows belongs to the operating system. c:\program files is appropriate. Or the GAC. Don't deploy the interop DLL, nobody has any use for that. – Hans Passant Mar 19 '14 at 18:17
  • Well let me expand on that. Coming from the pure COM world it does matter where you put the COM component if it is a common component used in the wild. The old DLL hell reminds me of this situation where developers did not deploy properly and we had different versioned components in different locations, typically in the app folder. Since the TLB has to be registered I am worried that this situation may resurface. meaning what if another developer decides to deploy our libraries and put them in say {sysdrive}\Windows and its an older version then we may end up with a mess. – sinDizzy Mar 19 '14 at 18:32
  • 1
    DLL Hell is caused by not changing the guids. Putting the DLL in the Windows system subdirectory makes it worse, there is only one. The TLB doesn't have to be registered for a VB6 app, it doesn't use threads. – Hans Passant Mar 19 '14 at 18:38
  • Ahhh I think I get it now. I think I was getting confused in referencing the TLB in my VB6 project with registering it. At the initial stages of development we didnt keep the GUID the same on subsequent versions of the TLB. When I went to work on the VB6 project it had lost its reference and thought it was due to registering it. But as you mention, the TLB does not need registering but the GUID does need to stay the same to keep compatibility. We did modify the process to keep the GUID the same on TLB versions and now it works when we update it. So as you mentioned just deploy to {pf}\MyLib. – sinDizzy Mar 19 '14 at 18:56

0 Answers0