Calling a VB.net(2008) assembly from classic asp

  • Thread starter Thread starter coyoterunner
  • Start date Start date
C

coyoterunner

Hello,
I am upgrading our VB 6.0 dll's to .net assemblies. They are used by
asp pages. The first assembly is created and runs fine from a console
app test harness. I used regasm /tlb /codebase and created a snk for
the assembly. I placed the net dll and the snk file in the same folder
on my local machine. The asp pages are in a project in the same
solution as the .net dll projects. When I run the asp project locally,
the new assembly cannot be created. When I step into the asp code, I
see 'children could not be evaluated' on set obj = Server.CreateObject
("dotNetDll.dotNetClass"). I tried a few variations of pathing for the
<Assembly: AssemblyKeyFile attribute.
I tried the complete path to the snk file(same path as the dll),
also ..\..file.snk
What am I missing?
 
Hi,


This is just a problem when debugging ? According tohttp://social.msdn.microsoft.com/Forums/en/vsdebug/thread/e66ea627-fb...
it seems to be expected.
(my understanding is so you'll be able to evaluate something exposed by .NET
only if you are stopped in .NET code etc...)

I believe you are correct. The asp page cannot create the object
though. It returns no error, just is not able to create it. I found an
article that talks about creating a class library using a Com class.
It creates a guid and registers it. That seemed to work partially. The
object was created, but the function could not be called.
 
Did you mark the .NET assembly with "Register for COM" within the project's
properties?

Did you recompile after generating the .snk from within Visual Studio?

Also, the .snk is only needed to sign the .NET file prior to compilation.
You should certainl save the .snk, but it does not get deployed with the
..NET assembly.

-Scott
 
I believe you are correct. The asp page cannot create the object
though. It returns no error, just is not able to create it.

Is this just a debugging issue or is this that it doesn't work (obj is not
created) and you try to debug this ?

Could it be that this library have dependencies other than .NET ? Still a
bit strange you don't see any error..

Good luck.
 
Did you mark the .NET assembly with "Register for COM" within the project's
properties?

Did you recompile after generating the .snk from within Visual Studio?

Also, the .snk is only needed to sign the .NET file prior to compilation.
You should certainl save the .snk, but it does not get deployed with the
.NET assembly.

-Scott






- Show quoted text -

Yes I marked it 'Register for Com'.
Yes I recompiled.
 
Is this just a debugging issue or is this that it doesn't work (obj is not
created) and you try to debug this ?

Could it be that this library have dependencies other than .NET ? Still a
bit strange you don't see any error..

Good luck.

It's both I think. Also strange is I can't step into the code.
Probably because the dll is not being created.
 
Hello,
I am upgrading our VB 6.0 dll's to .net assemblies. They are used by asp
pages. The first assembly is created and runs fine from a console app
test harness. I used regasm /tlb /codebase and created a snk for the
assembly. I placed the net dll and the snk file in the same folder on my
local machine. The asp pages are in a project in the same solution as
the .net dll projects. When I run the asp project locally, the new
assembly cannot be created. When I step into the asp code, I see
'children could not be evaluated' on set obj = Server.CreateObject
("dotNetDll.dotNetClass"). I tried a few variations of pathing for the
<Assembly: AssemblyKeyFile attribute. I tried the complete path to the
snk file(same path as the dll), also ..\..file.snk
What am I missing?

Perhaps you've been bitten by the following bug, which is caused by an
IE7 update that breaks .NET Interop:

http://support.microsoft.com/kb/945701

http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?
FeedbackID=294241

I experienced this when an employee of mime thought it would be smart to
add some .NET code to a legacy classic asp application. Although I
warned him about adding .NET to the application's list of dependencies,
some people just have to learn the hard way. His application is now
dependent on .NET and all the upgrade issues that go with it. Not a
smart move, if you ask me. New is not always better, especially when it
comes from MS.

For more info:

http://weblog.ikvm.net/CommentView.aspx?guid=9bdc9af1-7f46-482e-bd5a-
aed5fe82a2f5

http://blogs.msdn.com/sukeshak/archive/2007/09/18/installing-ms07-045-
cumulative-security-update-for-internet-explorer-createobject-call-fails-
with-8000ffff.aspx

http://blogs.msdn.com/sukeshak/archive/2007/12/20/
IE_2D00_Fix_2D00_945701.aspx

Peter
 
Back
Top