 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / .NET Framework / New Users / June 2007Location for References in projects
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,  SignatureRoger Tranchez MCTS .NET 2005 and DB developer > Hello, > [quoted text clipped - 16 lines] > How can I achieve this ? If possible, I don't want to use reflection > as if I'm not wrong I would loose intellisense... 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 -- Ror 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, SignatureRoger Tranchez MCTS .NET 2005 and DB developer > I am the only developer on the enterprise right now, and thus, I don't > use sourcesafe or other related stuff. [quoted text clipped - 4 lines] > installed MY program, some sort of config file, to reference the file > without having to recompile MY program. Is it possible ? 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 :) -- Ror 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. SignaturePhil Wilson [MVP Windows Installer] > Hello, > [quoted text clipped - 25 lines] > > Thanks in advance, 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. 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. SignaturePhil Wilson [MVP Windows Installer] > Hello, > [quoted text clipped - 35 lines] > > Roger Tranchez 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.
Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.