|
|
Giorgi Dalakishvili wrote: Is this what you are looking for: Window Tabifier[^] ?
#region signature
my articles
#endregion
Yes, This is very helpful. Thank you.
|
|
|
|
|
Glad to help you 
|
|
|
|
|
I have a .Net (2.0) assembly that I want to call using a Com client (a VB6 program) on another machine. I don't need it to be strong-named or in the GAC - the assembly will be in the same directory as the Com client.
So, based on various examples from googling, MSDN, etc., my process has been:
1. Make sure that the assembly [call it MyAssy.dll] has ComVisible
attribute set, and use both an interface and a class that implements the
interface.
2. Make sure that the assembly, the interface and the class are all
decorated with GUID attributes, and the Interface also has a ComVisible =
true attribute.
3. Build the .Net assembly.
4. On the .Net machine, regasm MyAssy.dll /tlb:MyAssy.TLB. This succeeds,
and I copy both the dll and the type library to the VB6 machine with .Net
2.0 framework installed.
5. Again, regasm MyAssy.dll /tlb:MyAssy.TLB (with correct paths everywhere.)
6. Open the VB project and add the reference to the type library. In the VB6
project I can now see the class and Intellisense shows me all its methods.
So far so good.
7. However, when I try to compile, I get Run-time error -2147024894
(800700002) Automation Error - Cannot find the file specified. The error
occurs when I instantiate an object from MyAssy.dll
The GUIDs in the registry appear to match the GUID for my class and the Type library. I have numerous times removed references, unregistered, verified that the GUIDs are gone from the registry, reregistered, and many other things but have not been able to solve this problem. Even more annoying, I did a proof-of-concept of this whole process several months ago, and it worked fine, and continues to work, on the same 2 machines. The difference here is that MyAssy.dll actually wraps another .Net DLL that actually does something useful, but even when I temporarily removed the reference to the useful .Net DLL from MyAssy.dll, I had the same problem.
I've been through lots of troubleshooting posts that told me to try all of the "fixes" in the above paragraph, but no go. Any idea what might be wrong?
Thanks much,
Elizabeth C.
|
|
|
|
|
Elizabeth Connolly wrote: 5. Again, regasm MyAssy.dll /tlb:MyAssy.TLB (with correct paths everywhere.)
Have you verified those paths in the resulting registry entries?
Also the Ole View tool that used to come with Visual Studio was a great way to verify a COM components registration and even instancing it. It is now a SAMPLE and you can download it[^], build it and run it to verify COM components are accessible.
led mike
|
|
|
|
|
Yes, I did verify the paths in the reg entries and they checked out.
I will try the OleView though. Thanks for the pointer!!!
|
|
|
|
|
Try adding the /codebase switch to regasm, that adds the path to the registry of where the DLL is located. If you don't then it assumes it's somewhere in the PATH variable.
|
|
|
|
|
Aha! I will try this. I hadn't done it because I thought /codebase would only work in certain situations, but I will for sure try it and see if it works. Thanks!
|
|
|
|
|
Unless your assembly is registered in the GAC or in the system path then you need this. However don't move the DLL once you've registered it with that command because it won't be able to find it then.
|
|
|
|
|
I have a few more questions:
1) If the Com-Visible "wrapper" DLL, which is Com registered and seen by Com clients, wraps another DLL, does this other DLL also need to be COM Visible, registered via regasm /codebase, etc.? My Com DLL references another which references several others. Do all the DLLs need to be COM Visible? I thought that it was only the wrapper that had to be visible but maybe this is not the case?
2) And are there any bad side effects for other .Net applications that also consume a COM-Visible DLL (but not through Com)?
Thanks!
|
|
|
|
|
1) No, if it's wrapping it through .NET code.
2) Not that I know of, depends on how you code it mostly. Situation dependent (e.g. accessing shared resources).
|
|
|
|
|
Thanks, Ed!
I will put in some logging or something to try to figure out why the calls to my wrapper dll seem to do nothing on the com machine, but have the intended effect on the .Net machine.
Glad to hear it took you 2 weeks to get this working; I have been pulling my hair out over it since Friday!
|
|
|
|
|
THAT WORKS! You're a genius!
Now I have to debug the assembly, which doesn't seem to work, but at least I can compile!
THANK YOU!!!! 
|
|
|
|
|
Don't worry it took me 2 weeks to get that little gem working to call a C# dll in Delphi 5.
|
|
|
|
|
How do I keep people from browsing sub folders on a .net website?
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
how about adding a simple index.htm file in each of them?
Luc Pattyn [Forum Guidelines] [My Articles]
This month's tips:
- before you ask a question here, search CodeProject, then Google;
- the quality and detail of your question reflects on the effectiveness of the help you are likely to get;
- use PRE tags to preserve formatting when showing multi-line code snippets.
|
|
|
|
|
Index.html won't do it because it's a .net site. Right now, I'm using a Default.aspx file set in each sub folder.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
Authentication and a web.config in the subfolders you want to be protected.
|
|
|
|
|
But the catch is non-ASPNET parseable resources still bypass aspnet_isapi.dll and web.config may not be able to halt them. An IIS level control is required.
Vasudevan Deepak Kumar
Personal Homepage
Tech Gossips
A pessimist sees only the dark side of the clouds, and mopes; a philosopher sees both sides, and shrugs; an optimist doesn't see the clouds at all - he's walking on them. --Leonard Louis Levinson
|
|
|
|
|
True - but John is working on a .NET site so he's probably got the necessarys right there.
|
|
|
|
|
Check this out http://www.peterprovost.org/archive/2003/05/16/470.aspx[^]
There is also a hidden catch.
But the catch is non-ASPNET parseable resources still bypass aspnet_isapi.dll and web.config may not be able to halt them. An IIS level control is required.
Vasudevan Deepak Kumar
Personal Homepage
Tech Gossips
A pessimist sees only the dark side of the clouds, and mopes; a philosopher sees both sides, and shrugs; an optimist doesn't see the clouds at all - he's walking on them. --Leonard Louis Levinson
|
|
|
|
|
Need authentication integration, or something simple?
Theres a couple of free .htaccess solutions kicking around.
If you want the integration have a google for the wildcard mapping in IIS to convince it to push all requests thru the ASP.Net isapi dll...
Messy though... are you sure you can't stream the files out (using URL rewriting if you really need nice paths)? Actually you could probably have a generic handler using URL rewriting to pick the file off disk and stream it out. Messy again though heh.
|
|
|
|
|
Am I missing something? What about the "Directory Browsing" check box in the IIS console properties?
led mike
|
|
|
|
|
You must have forgotten that I'm not using IIS...
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
John Simmons / outlaw programmer wrote: You must have forgotten that I'm not using IIS...
that or I never knew to begin with.  What are you using?
led mike
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
