Location for References in projects

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Hello,

I have a question wich I should already now its answer, but here I go...

I 'm developing a windows application (.NET 2.0) wich has a reference to a
component (a tlb file) that resides on a certain place in our local network;
let's say it's ...

\\serverapp\SIGRID2\Sigrid.tlb

This place, is the shared folder for an application called "Sigrid".

If someday, somehow, we turn "upside down" our network structure and this
file changes its place, I would want to change something in the settings file
or somewhere, from my application, without having to re-compile my project.

How can I achieve this ? If possible, I don't want to use reflection as if
I'm not wrong I would loose intellisense...

If the only way to do it is by reflection, it will not work with
assembly.loadfrom as it works only with NET assemblies, it isn't ?

So, what's the best way ?

Thanks in advance,
 
Hello,
I have a question wich I should already now its answer, but here I
go...

I 'm developing a windows application (.NET 2.0) wich has a reference
to a component (a tlb file) that resides on a certain place in our
local network; let's say it's ...

\\serverapp\SIGRID2\Sigrid.tlb

This place, is the shared folder for an application called "Sigrid".

If someday, somehow, we turn "upside down" our network structure and
this file changes its place, I would want to change something in the
settings file or somewhere, from my application, without having to
re-compile my project.

How can I achieve this ? If possible, I don't want to use reflection
as if I'm not wrong I would loose intellisense...
Click to expand...

I'm not sure I understand what reflection might have to do with this.

I would check this reference and any of it's dependancies into sourcecontrol
somewhere.
then I would get a copy of these files (through sourcecontrol) to my local
HD and reference them from there.

We use a directory structure like....

-------------------------------------------------------------
c:\Integration
\3rdParty
\NUnit
\DevExpress
\Solution1
\Project1
\Project2
\Reference
\Solution2
\Project1
\Project2
\Reference
-------------------------------------------------------------

We keep all our files on Local HD in this format.

-------------------------------------------------------------
Sidenote: We do not store the files locally on the C:\. They might be anywhere
on any given machine. We create a junction point (Search Google for Junction
Magic) from whereever the files truely are, to the integration folder. This
means that everone has the same (apparent) local file structure and it makes
our build process a lot easier.

Most people choose to have this real directory on their D: but machines do
not have one.
-------------------------------------------------------------

All projects build within Studio to their respective bin folders and we use
Nant to build each again to a release directory for that solution.
All references are made from either one of the 3rdParty sub directories or
the reference folder for the relavent solution.

If I needed to reference the file you suggest, then we would include it somewhere
beneath our 3rdParty folder and simply get latest from source control. This
ensures that we don't need to worry about network or indeed machine topology
as the files are always available in the exact same absolute location on
everyone's local machine.

The only issue is.... are they up-to-date

I hope this helps
 
Hello,

Thanks for your answer, really, but I think that my question does not have a
relation with source control; I will try to explain it better:

The .tlb file I want to reference is in a production environment; it belongs
to ANOTHER PROGRAM called "Sigrid" and I cannot copy or move it. I have to
reference this and only this file, from MY already compiled program
(residing on its own network folder).

I am the only developer on the enterprise right now, and thus, I don't use
sourcesafe or other related stuff.

If some day the people that do program installations and network management
change the location of that file (and the associated program folder), I would
like to change, on the folder where I installed MY program, some sort of
config file, to reference the file without having to recompile MY program. Is
it possible ?

I was talking about reflection but I was wrong, as it relates to NET
assemblies only... sorry

I hope it helps for the sake of clarity.

Thanks again,
 
I am the only developer on the enterprise right now, and thus, I don't
use sourcesafe or other related stuff.

If some day the people that do program installations and network
management change the location of that file (and the associated
program folder), I would like to change, on the folder where I
installed MY program, some sort of config file, to reference the file
without having to recompile MY program. Is it possible ?
Click to expand...

Ok fair enough, I think I understand now :)

This is similar in nature to a product we have which has dependancies on
Crystal reports and therefore 1 or 2 of the Dlls that make up the crystal
runtime.

Our app is compiled VB6 (therefore win32) though, so I can't guarentee that
the following would apply to you dotnet situation.

We have found that people keep doing nasty things with the crystal dlls that
we depend on. They overwrite thenm with earlier/later version and sometimes
they flat out delete/uninstall them.

You have said the thing you depend on is a TLB. As I understand things TLB's
are usually registered in the registry and therefore your application likely
as not, has a reference not to the tlb but to some guid representing it.
As long as you register the TLB file (using RegSvr32.exe) on the system on
which your exe is going to run, the windows should continue be able to locate
this file for you.

There is also a mechanism in Win2000 or better wherein you can create a file
(zero byte) called "MyExe.exe.local" (where MyExe is the name of the actual
exe you are going to be running) and this will cause windows search the local
director for any dll references it needs before searching anywhere else.
we use this to allow us to xcopy deploy the require crystal dlls to our own
application's directory and avoid any issues with other people/programs messing
with the ones in system32.

Maybe some of this will be of more help to you :)
 
Keep in mind that you do not have a reference to that TLB if you're
developing in managed code. When you referenced it, Visual Studio did a
tlbimp behind your back and what you have now in your project is a ref to an
interop assembly that maps the calls to the COM classes described by that
TLB. It's not clear to me when (if ever) Visual Studio goes back to look at
that TLB and regenerate the interop assembly.
 
Hello,

Thanks for answering. You said...
Keep in mind that you do not have a reference to that TLB if you're
developing in managed code. When you referenced it, Visual Studio did a
tlbimp behind your back and what you have now in your project is a ref to an
interop assembly that maps the calls to the COM classes described by that
TLB.
Click to expand...

Oh my god, .... In fact, I noticed that the program works even if I do NOT
add that reference, as the TLB is registered on my system. But I don't get
Intellisense to work if I don't import. I suppose it is a price to pay.

So, the best way to do this is NOT REGISTER any TLB. OK ?

The technical stuff from the company that made that COM component said that
I should use that TLB from its original place as it contains "embedded"
permissions in the file itself, and that if I copy the component to another
folder it will not find licenses and it will not work... I suppose that, or
they do not know that creating the reference from NET creates a wrapped
component that will invalidate licenses, or they do NOT work with NET ...
Could it be ? oh man, that's getting interesting...

Also, another doubt: the tlb and the associated dll are on a network share.
Whey the component is registered ON A LOCAL PC, I suppose that the reference
still points to the network share as it contains the infamous licenses they
talk about... Could it be (again) ?

Thanks again and Bye-bye,

Roger Tranchez
 
There's no need to register it in your case because you're using the
generated interop assembly. What kind of Dll is it? Win32? Sounds like it
might be, so maybe they ship the TLB so people can develop without having
the actual COM Dll. The other wrinkle is that Win32 Dlls typically contain
the typelib anyway, so registering the Dll would also register the typelib
info. Embedded licenses, no idea what's going on there. I'd expect
licensing to be in the code somewhere, not in the typelib, because the
typelib is just a description of COM interfaces that are implemented in the
Dll.
 
Hi Roger,

I agree with Phil. For the TLB file you mentioned, it is just a type
library file which supplies the Type LIbrary(such as COM class and
interfaces definition) of the actual COM component. And sometimes TLB info
will be merged into the COM dll together. So sometimes you will directly
add reference against the dll file rather than a separate tlb file.

Also, for referencing such COM component in .net framework application, the
tlb (type library) is only necessary at development time(when you need to
compile/build the code in IDE or command line or need IDE to show
intellisense). Visual Studio IDE use tlb(type library) to get the COM class
and interface signature and structure so as to provide intellisense
support. However, after you compiled the program and run the problem,
tlb is no longer necessary, the actual COM component and the generated
interop assembly are the necessary runtime dependency. Your .net
application actually only reference the interop assembly(generated from TLB
when you add reference) in its .NET manifest. And at runtime, .net clr
runtime use a fixed approach and rule to locate the referenced dependency
assemblies(managed one):

#How the Runtime Locates Assemblies
http://msdn2.microsoft.com/en-us/library/yx7xezcf(VS.80).aspx

For tlb, you just need to make sure you can find it at development
time(when using Visual Studio IDE).

If you have any further questions, please feel free to post here.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead



==================================================

Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.



Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.

==================================================


This posting is provided "AS IS" with no warranties, and confers no rights.
 
Back
Top