Deploying Interop files

  • Thread starter Thread starter Harry Simpson
  • Start date Start date
H

Harry Simpson

Couple of questions:

If i have a ThirdParty.DLL and set a reference to it, it creates the
interopThirdParty.DLL in the BIN directory.

As for deployment:
1. Is it best to include the ThirdParty.DLL in the BIN with the
interopThirdParty.DLL?
2. Using Wise for the install, do I have to register ThirdParty.DLL on the
target server?

As for VSS:
1. None of the files in the BIN are ever saved to VSS. Should I create a
directory to save the latest greatest DLLs into VSS?

Inquiring minds want to know.

Harry
 
Hi Harry,
1. Is it best to include the ThirdParty.DLL in the BIN with the
interopThirdParty.DLL?
Click to expand...

No. COM objects are registered in the System registry with their DLL file
location, which is why COM objects don't use a \bin folder. As .Net
assemblies are not registered, they must reside in a known location, such as
the \bin folder of an app, or the Global Assembly Cache. Only the Interop
DLL should go in the \bin folder.
2. Using Wise for the install, do I have to register ThirdParty.DLL on the
target server?
Click to expand...

If you are not sure whether the COM class you are using is
installed/registered on the target machine, yes.
1. None of the files in the BIN are ever saved to VSS. Should I create a
directory to save the latest greatest DLLs into VSS?
Click to expand...

That is entirely your call. As the code creates the DLL, we don't store DLLs
in VSS, only the code. Also, if you add the DLLs in your Project output
folder to VSS, you will have to check them out each time you compile.

--
HTH,
Kevin Spencer
..Net Developer
Microsoft MVP
Big things are made up
of lots of little things.
 
Thanks Kevin,

Re 1 answer: Then if one unregisters, moves a dll, and re-registers that
DLL, should the reference in .NET be deleted and added again?
in VSS, only the code.
Click to expand...

I was thinking more of a somewhat shared environment where developers would
check out a web app to their local machine from VSS. Perhaps one of the
developers received an updated third party dll, how would the other
developers get this latest DLL to use?

We are trying to make our dev environment more accessible via VSS to all the
other developers.

TIA
Harry
 
Hi Harry,
Re 1 answer: Then if one unregisters, moves a dll, and re-registers that
DLL, should the reference in .NET be deleted and added again?
Click to expand...

The location of the COM DLL is unimportant. The registry information is used
by the Interop Assembly.
I was thinking more of a somewhat shared environment where developers would
check out a web app to their local machine from VSS. Perhaps one of the
developers received an updated third party dll, how would the other
developers get this latest DLL to use?
Click to expand...

Assuming that you're using Visual Studio.Net to build your assemblies, you
should use Visual Studio.Net to add and work with Visual SourceSafe, as it
knows how to add a project correctly. By default VS.Net does not add
assemblies to VSS (the same reason I gave before), nor does it add the
folders the DLLs reside in. It only adds code files and project files. It is
best to only store projects (not solutions) in VSS, so that you can use
assemblies that are common to different solutions in multiple solutions, and
you don't have to check out your solution every time you do something that
changes your solution file.

--
HTH,
Kevin Spencer
..Net Developer
Microsoft MVP
Big things are made up
of lots of little things.
 
Kevin,

This thread could go on for ever i guess....
Seems like this would be exactly why you would store the solution file in
VSS.

Guess everyone would keep third party dlls on their local box with new
versions simply emailed to the team for inclusion on their dev machines.

TIA
Harry
 
Back
Top