Discussion:
FileNotFoundException Loading ActiveX dll
(too old to reply)
amdrit
2009-10-28 20:03:28 UTC
Permalink
Raw Message
I have a C# assembly that makes reference to a VB 6 library. Durning
runtime, when I attempt to create an instance of my Vb 6 class object, I
receive a FileNotFoundException. I have no idea where to start figuring
this one out.

When I make refernce to the VB6 dll, C# creates the Interop wrapper for me.
That is the file that generates the FileNotFoundException. The C# dll is
loaded via MSTSC via the RDP virtual channels and that is the only
difference when referencing the VB 6 library.

I can create a simple windows forms application, reference my Vb 6 library,
and it will execute fine.

What I am wondering is, do I need to put the interop wrapper somewhere else
for it to work as expected with my intended solution?
mayayana
2009-10-28 21:23:54 UTC
Permalink
Raw Message
You already have this posted in the interop
newsgroup. That's where it should be. You could
also post here:
microsoft.public.dotnet.languages.vb

The VB group:
microsoft.public.vb.general.discussion
should be dropped from further posts. You might
be using a VB6 class but .Net and interop are
"all Greek" from VB point of view.
Post by amdrit
I have a C# assembly that makes reference to a VB 6 library. Durning
runtime, when I attempt to create an instance of my Vb 6 class object, I
receive a FileNotFoundException. I have no idea where to start figuring
this one out.
When I make refernce to the VB6 dll, C# creates the Interop wrapper for me.
That is the file that generates the FileNotFoundException. The C# dll is
loaded via MSTSC via the RDP virtual channels and that is the only
difference when referencing the VB 6 library.
I can create a simple windows forms application, reference my Vb 6 library,
and it will execute fine.
What I am wondering is, do I need to put the interop wrapper somewhere else
for it to work as expected with my intended solution?
amdrit
2009-10-28 21:30:17 UTC
Permalink
Raw Message
So you are suggesting that I am the only person that is using VB 6 and .Net
in this manner? Some VB 6 users may not use the Interop forum, no since in
limiting my exposure. But thanks for detracting from the subject at hand.
Post by mayayana
You already have this posted in the interop
newsgroup. That's where it should be. You could
microsoft.public.dotnet.languages.vb
microsoft.public.vb.general.discussion
should be dropped from further posts. You might
be using a VB6 class but .Net and interop are
"all Greek" from VB point of view.
Post by amdrit
I have a C# assembly that makes reference to a VB 6 library. Durning
runtime, when I attempt to create an instance of my Vb 6 class object, I
receive a FileNotFoundException. I have no idea where to start figuring
this one out.
When I make refernce to the VB6 dll, C# creates the Interop wrapper for
me.
Post by amdrit
That is the file that generates the FileNotFoundException. The C# dll is
loaded via MSTSC via the RDP virtual channels and that is the only
difference when referencing the VB 6 library.
I can create a simple windows forms application, reference my Vb 6
library,
Post by amdrit
and it will execute fine.
What I am wondering is, do I need to put the interop wrapper somewhere
else
Post by amdrit
for it to work as expected with my intended solution?
mayayana
2009-10-28 23:06:27 UTC
Permalink
Raw Message
Post by amdrit
So you are suggesting that I am the only person
that is using VB 6 and .Net
in this manner? Some VB 6 users may not use the
Interop forum, no since in limiting my exposure
I'm not suggesting you're the only person using VB6
with interop. I'm just trying to explain which group is
which, for everyone's sake. This group is only for VB6
and lower. Many of us know nothing of .Net. If you
want to ask a question about the VB6 part then this is
a good place. If you want to ask about the interop/
.Net part then you need to ask in a .Net group where
people know what you're talking about. ...Better for you
and better for everyone else.
Eduardo
2009-10-28 22:23:24 UTC
Permalink
Raw Message
Post by mayayana
I'm not suggesting you're the only person using VB6
with interop.
LOL.
Of course not!
May be... a couple of dozens?
mayayana
2009-10-29 03:31:20 UTC
Permalink
Raw Message
Post by Eduardo
Post by mayayana
I'm not suggesting you're the only person using VB6
with interop.
LOL.
Of course not!
May be... a couple of dozens?
Interesting question. I wonder. There was a discussion
in the VBScript group recently about PowerShell and how
it incorporates .Net. I was thinking that MS is building
.Net into something as central as PowerShell -- and
they've got interop anyway -- so why not just stop
beating around the bush and add COM interfaces? Then
.Net could be used by VBScript, where the speed,
decompilability and massive dependencies would be
far less of a liability. With Dispatch COM interfaces I think
I'd even install the Framework myself. It would turn script
into a highly capable "fast and dirty" programming
language.
Tom Shelton
2009-10-29 04:57:14 UTC
Permalink
Raw Message
Post by mayayana
Post by Eduardo
Post by mayayana
I'm not suggesting you're the only person using VB6
with interop.
LOL.
Of course not!
May be... a couple of dozens?
Interesting question. I wonder. There was a discussion
in the VBScript group recently about PowerShell and how
it incorporates .Net.
PowerShell was written in a .NET language - probably C++/CLI - but you can
write cmdlets in C#... It doesn't just incorporate .NET - it is .NET.
Post by mayayana
I was thinking that MS is building
.Net into something as central as PowerShell
.NET is not built into PowerShell - PowerShell is built on .NET.
Post by mayayana
-- and
they've got interop anyway -- so why not just stop
beating around the bush and add COM interfaces?
Dude, it's almost childs play to expose .NET functionality to COM. Interop
goes both ways.
Post by mayayana
Then
.Net could be used by VBScript, where the speed,
decompilability and massive dependencies would be
far less of a liability. With Dispatch COM interfaces I think
I'd even install the Framework myself. It would turn script
into a highly capable "fast and dirty" programming
language.
PowerShell. That's what it is. Geeze. You can use COM objects, do WMI, etc,
etc, etc. My powershell book even has a simple web server example...
--
Tom Shelton
mayayana
2009-10-29 15:31:02 UTC
Permalink
Raw Message
Post by Tom Shelton
Dude, it's almost childs play to expose .NET functionality to COM.
Interop
Post by Tom Shelton
goes both ways.
.......
Post by Tom Shelton
PowerShell. That's what it is. Geeze. You can use COM objects, do WMI, etc,
etc, etc. My powershell book even has a simple web server example...
Yes, but PowerShell is primarily a command
line tool. It's souped-up DOS that was apparently
designed to appeal to Unix/Linux admins who
would like to have familiar tools if they're going to
move to Windows PCs. It's good for network admins,
but not well-suited to GUI level.

The ability to reach COM from .Net is not what
I had in mind. If I had to go to the trouble of getting
into .Net then there wouldn't be any point.

I meant that it would be nice to have the
.Net objects install with Dispatch interfaces, so
that one could write VBScript, HTAs, etc. (Windows
GUI scripting, in other words, not "NT-DOS" command
line) that can dependably run on most systems.
In other words, make .Net objects useful to other
tools by remaking them as COM objects.

Someone said one day that there's a compact
.Net runtime coming for Silverlight. (?) That would
be an even better place to put Dispatch interfaces,
giving Windows scripters a new GUI toolbox that's
easy to install.

Just a thought. I was just thinking that since MS
is blending .Net into Windows -- and thereby probably
setting the stage for the same security disaster that
befell IE with ActiveX -- they might just as well go
whole hog and add COM to .Net so that it's fully
adapted to Windows.
Tom Shelton
2009-10-29 15:16:18 UTC
Permalink
Raw Message
Post by amdrit
Post by Tom Shelton
Dude, it's almost childs play to expose .NET functionality to COM.
Interop
Post by Tom Shelton
goes both ways.
.......
Post by Tom Shelton
PowerShell. That's what it is. Geeze. You can use COM objects, do WMI,
etc,
Post by Tom Shelton
etc, etc. My powershell book even has a simple web server example...
Yes, but PowerShell is primarily a command
line tool. It's souped-up DOS that was apparently
designed to appeal to Unix/Linux admins who
would like to have familiar tools if they're going to
move to Windows PCs. It's good for network admins,
but not well-suited to GUI level.
And VBScript is? It's a shell scripting environment. It's like VBScript on
steroids. And besides, you can write gui's using powershell if you want - you
have access to windows forms libraries - it's a .NET environment after all.

You really haven't used it have you?
Post by amdrit
The ability to reach COM from .Net is not what
I had in mind. If I had to go to the trouble of getting
into .Net then there wouldn't be any point.
I meant that it would be nice to have the
.Net objects install with Dispatch interfaces, so
that one could write VBScript, HTAs, etc. (Windows
GUI scripting, in other words, not "NT-DOS" command
line) that can dependably run on most systems.
In other words, make .Net objects useful to other
tools by remaking them as COM objects.
I'm not going to get into the COM thing, though, COM is becomming decreasingly
important. But, again it's very easy to create COM wrappers for .NET
functionality...
Post by amdrit
Someone said one day that there's a compact
.Net runtime coming for Silverlight. (?) That would
be an even better place to put Dispatch interfaces,
giving Windows scripters a new GUI toolbox that's
easy to install.
Just a thought. I was just thinking that since MS
is blending .Net into Windows -- and thereby probably
setting the stage for the same security disaster that
befell IE with ActiveX -- they might just as well go
whole hog and add COM to .Net so that it's fully
adapted to Windows.
.NET is not ActiveX. ActiveX had almost no security build into it at all. It
was not written for an internet world. .NET in the browser, is more along the
lines of Java Appletts. They are sandboxed and run with limited permissions.
No system is perfect - I imagine there will be issues from time to time, just
as there has been with Java. But, it's not going to be anything like the
ActiveX thing.
--
Tom Shelton
mayayana
2009-10-29 16:47:49 UTC
Permalink
Raw Message
Post by Tom Shelton
Post by mayayana
Just a thought. I was just thinking that since MS
is blending .Net into Windows -- and thereby probably
setting the stage for the same security disaster that
befell IE with ActiveX -- they might just as well go
whole hog and add COM to .Net so that it's fully
adapted to Windows.
.NET is not ActiveX. ActiveX had almost no security
build into it at all. It was not written for an internet
world. .NET in the browser, is more along the
lines of Java Appletts. They are sandboxed and run
with limited permissions.
No system is perfect -
ActiveX was designed for the Web. A control can be
marked as safe -- or not. It can be signed. But the MS
strategy of trying to get market share by tying their system
to the Internet was a problem. ActiveX is poorly suited
for software and unsafe online. I use ActiveX a lot now,
but mainly only for Windows scripting.

It looks to me like MS is doing the same thing with
.Net. It's sandboxed, but on Windows there's API access
and unmanaged code. And it's getting tied into the system.
How long will it be before there are online PowerShell
hacks? Or other .Net-based attacks? There was an
article recently pointing out that anything that can replace
a .Net runtime file can commandeer all .Net software on
the system. That's not a big risk at this point, but I wouldn't
want to be running anything .Net online.

So it's starting to look like the same problem: A tool
that's poorly suited to Windows software but doomed
online by it's intimate connection to the Windows system.
That's not a problem that Java has.

Thus my thought that some Dispatch interfaces might
make .Net rather attractive. :)
Tom Shelton
2009-10-29 16:59:54 UTC
Permalink
Raw Message
Post by mayayana
Post by Tom Shelton
Post by mayayana
Just a thought. I was just thinking that since MS
is blending .Net into Windows -- and thereby probably
setting the stage for the same security disaster that
befell IE with ActiveX -- they might just as well go
whole hog and add COM to .Net so that it's fully
adapted to Windows.
.NET is not ActiveX. ActiveX had almost no security
build into it at all. It was not written for an internet
world. .NET in the browser, is more along the
lines of Java Appletts. They are sandboxed and run
with limited permissions.
No system is perfect -
ActiveX was designed for the Web. A control can be
marked as safe -- or not. It can be signed. But the MS
strategy of trying to get market share by tying their system
to the Internet was a problem. ActiveX is poorly suited
for software and unsafe online. I use ActiveX a lot now,
but mainly only for Windows scripting.
Unsafe online because it had almost no real security built in. Just because a
control was marked as safe didn't make it so.
Post by mayayana
It looks to me like MS is doing the same thing with
.Net. It's sandboxed, but on Windows there's API access
and unmanaged code.
Which you can't use from a browser app. See, .NET has this thing called Code
Access Security (CAS). In the browser context that is not allowed - unless the user
specifically goes in and alters policy settings. That's the point of having a
JIT and the runtime. The runtime checks to make sure that the code it is
about to compile and run is safe in the current context.
Post by mayayana
And it's getting tied into the system.
How long will it be before there are online PowerShell
hacks?
You can't run remote scripts in powershell by default. In fact, you can't run
scripts at all by default - you can only work interactive on the intial setup.
Most people probably set their execution policy to RemoteSigned - which means
you can't run remote scripts unless they are signed and trusted.
Post by mayayana
Or other .Net-based attacks? There was an
article recently pointing out that anything that can replace
a .Net runtime file can commandeer all .Net software on
the system. That's not a big risk at this point, but I wouldn't
want to be running anything .Net online.
.NET has been out there for almost 10 years now. Please point to all of the
.NET viruses and attacks? There are always theoretical attacks, but I just
don't think what your talking about is even practicle. It certainly wouldn't
be easy to do given the number of items that would have to be spoofed just to
get the dll to load.

In fact, replacing a runtime file will probably render anything .net
inoperable, as it will net meet the critera to be loaded
Post by mayayana
So it's starting to look like the same problem: A tool
that's poorly suited to Windows software but doomed
Only in your mind. In fact, it's very suited to windows software.
Post by mayayana
online by it's intimate connection to the Windows system.
Again, you don't know what your talking about. It takes very specific actions
by the user to be able to enable anything from a partial trust environment
that can potentially do damage.

Believe me, I went through this with an XBAB application I was working on a
couple of years ago...
Post by mayayana
That's not a problem that Java has.
Thus my thought that some Dispatch interfaces might
make .Net rather attractive. :)
Make them you self. It's not hard.
--
Tom Shelton
Karl E. Peterson
2009-10-29 18:13:45 UTC
Permalink
Raw Message
Post by Tom Shelton
.NET has been out there for almost 10 years now. Please point to all of the
.NET viruses and attacks?
Yeah, but it's no more ubiquitous than Ubuntu. The attacks always go for the
easiest targets, and until you can count on there being a given flamework in place
why would anyone bother with that one?
--
.NET: It's About Trust!
http://vfred.mvps.org
Tom Shelton
2009-10-29 18:30:50 UTC
Permalink
Raw Message
Post by Karl E. Peterson
Post by Tom Shelton
.NET has been out there for almost 10 years now. Please point to all of the
.NET viruses and attacks?
Yeah, but it's no more ubiquitous than Ubuntu. The attacks always go for the
easiest targets, and until you can count on there being a given flamework in place
why would anyone bother with that one?
I very rarely deal with systems that don't at least have 1.0 or 1.1 runtime
installed (at my place of employment all multi-thousands of machines are on
the lattes 3.5sp1) - and Vista and up all have a runtime installed by default, not
counting the thousands if not millions of webservers running asp pages.
Believe, me the framework is much more ubiquitous then Ubuntu.
--
Tom Shelton
Karl E. Peterson
2009-10-29 18:33:35 UTC
Permalink
Raw Message
Post by Tom Shelton
Post by Karl E. Peterson
Post by Tom Shelton
.NET has been out there for almost 10 years now. Please point to all of the
.NET viruses and attacks?
Yeah, but it's no more ubiquitous than Ubuntu. The attacks always go for the
easiest targets, and until you can count on there being a given flamework in place
why would anyone bother with that one?
I very rarely deal with systems that don't at least have 1.0 or 1.1 runtime
installed (at my place of employment all multi-thousands of machines are on
the lattes 3.5sp1) - and Vista and up all have a runtime installed by default, not
counting the thousands if not millions of webservers running asp pages.
Believe, me the framework is much more ubiquitous then Ubuntu.
Not much. Nice anecdote. (And, btw, ASP is .NET-free ;-)
--
.NET: It's About Trust!
http://vfred.mvps.org
Tom Shelton
2009-10-29 18:46:42 UTC
Permalink
Raw Message
Post by Karl E. Peterson
Post by Tom Shelton
Post by Karl E. Peterson
Post by Tom Shelton
.NET has been out there for almost 10 years now. Please point to all of the
.NET viruses and attacks?
Yeah, but it's no more ubiquitous than Ubuntu. The attacks always go for the
easiest targets, and until you can count on there being a given flamework in place
why would anyone bother with that one?
I very rarely deal with systems that don't at least have 1.0 or 1.1 runtime
installed (at my place of employment all multi-thousands of machines are on
the lattes 3.5sp1) - and Vista and up all have a runtime installed by default, not
counting the thousands if not millions of webservers running asp pages.
Believe, me the framework is much more ubiquitous then Ubuntu.
Not much. Nice anecdote. (And, btw, ASP is .NET-free ;-)
I think you know I meant aspx :)

Not much? Vista alone has about 18% market share - with a guarenteed 3.0
runtime. Linux has about .97% market share on the desktop and apples is up to
what 6 or 7%? There are more machines with the framework on just vista then
apple and linux combined (not to mention that Ubuntu generally has a mono
installation installed by default - so you can't necessarily escape a .NET
implementation simply by going to Linux - or even OS X since some of them are
probably running a mono installation as well, I have it on my debian machine, my
gentoo machine, and my ubuntu machine)....
--
Tom Shelton
Karl E. Peterson
2009-10-29 18:53:56 UTC
Permalink
Raw Message
Post by Tom Shelton
Post by Karl E. Peterson
Post by Tom Shelton
Believe, me the framework is much more ubiquitous then Ubuntu.
Not much. Nice anecdote. (And, btw, ASP is .NET-free ;-)
I think you know I meant aspx :)
<g>
Post by Tom Shelton
Not much? Vista alone has about 18% market share - with a guarenteed 3.0
runtime.
Well, there ya go. So all generalities are indeed false, then! QED. ;-)

I'd still say that's a pretty small share to go after, if you're out to cause
trouble. And that was the original point, right? I mean, just imagine how puny
that number is in comparison to, say, MSVBVM50.DLL and/or MSVBVM60.DLL availability.
Not even H1N1 can succeed if 82% of the "market" is immunized.
--
.NET: It's About Trust!
http://vfred.mvps.org
Tom Shelton
2009-10-29 19:45:32 UTC
Permalink
Raw Message
Post by Karl E. Peterson
Post by Tom Shelton
Post by Karl E. Peterson
Post by Tom Shelton
Believe, me the framework is much more ubiquitous then Ubuntu.
Not much. Nice anecdote. (And, btw, ASP is .NET-free ;-)
I think you know I meant aspx :)
<g>
Post by Tom Shelton
Not much? Vista alone has about 18% market share - with a guarenteed 3.0
runtime.
Well, there ya go. So all generalities are indeed false, then! QED. ;-)
I'd still say that's a pretty small share to go after, if you're out to cause
trouble.
Yes, it probably would be if that were it. But, it's also on a great many
more desktop machines then just Vista.

It's hard to find hard an exact figure, but everything I can find
seems to indicate it's quite a large percentage of pc's. The framework ships
with ati graphics cards, hp scanning devices, and microsoft mouse software.
It's part of some versions of office 2003, it's preloaded by a lot of OEM's
(one ms blog said 85% of pc's shiped with a framework in 2004).

So, a person could probably safely target the 1.1 runtime and do some major
damage IF they were so inclined.
Post by Karl E. Peterson
And that was the original point, right? I mean, just imagine how puny
that number is in comparison to, say, MSVBVM50.DLL and/or MSVBVM60.DLL availability.
I'm not comparing it to those runtimes, as those have been distributed on
several versions of windows by default for a while. Vista was the first OS to
come with the framework preinstalled.
--
Tom Shelton
Karl E. Peterson
2009-10-29 19:50:43 UTC
Permalink
Raw Message
Post by Tom Shelton
So, a person could probably safely target the 1.1 runtime and do some major
damage IF they were so inclined.
Probably. But as I said, it's clear there are far bigger targets ripe for the
plucking.
Post by Tom Shelton
Post by Karl E. Peterson
And that was the original point, right? I mean, just imagine how puny
that number is in comparison to, say, MSVBVM50.DLL and/or MSVBVM60.DLL availability.
I'm not comparing it to those runtimes, as those have been distributed on
several versions of windows by default for a while. Vista was the first OS to
come with the framework preinstalled.
Right, there can be no meaningful comparison, whatsoever. :-)
--
.NET: It's About Trust!
http://vfred.mvps.org
mayayana
2009-10-29 23:54:48 UTC
Permalink
Raw Message
Post by Tom Shelton
Post by mayayana
It looks to me like MS is doing the same thing with
.Net. It's sandboxed, but on Windows there's API access
and unmanaged code.
Which you can't use from a browser app. See, .NET has
this thing called Code
Access Security (CAS). In the browser context that is
not allowed - unless the user
specifically goes in and alters policy settings.
You make a number of detailed points about how .Net
security works, but that doesn't mean it can't end up having
vulnerabilities. You say it's got protection in the browser,
yet Silverlight is .Net. Flash is also thought to be safe,
except when it isn't.
So what I'm saying is that MS is taking the same route
they took with ActiveX: leveraging the Windows monopoly
to gain market share online and vice versa. And it's likely
to come back to haunt them.
Post by Tom Shelton
Post by mayayana
Thus my thought that some Dispatch interfaces might
make .Net rather attractive. :)
Make them you self. It's not hard.
You missed my point. The only usefulness I
see for .Net is if it's widely installed and has
COM interfaces. I don't want to use .Net. But
if it had COM interfaces I might find uses for
.Net in scripting. If I'm going to have to make
components myself, and then people can't use
my scripts without those components, then VB6
is the ideal tool for that. (I think even you would
agree with that.) It can easily create
dual-interface COM components that are well-
suited to Windows. To choose instead to write
wrappers for .Net would be ridiculous. I'd be
bringing in dependencies, limitations, bloat, and
a lot of extra work, for no reason at all.

Then again, you said "COM is becomming decreasingly
important". If you can say that the week after a
new version of Windows has come out -- just as
COM-centric as ever -- then... why do I bother? :)

You also may have missed the point about
powershell vs scripting. I didn't mean to say that
VBScript is graphical. I meant that VBS - and the
Windows Script Host (WSH) - is designed for a GUI
system. DOS command line was for DOS. When
Windows came in with a GUI the WSH was provided
as a tool designed to work with a GUI system.
PowerShell is a return to console. I wasn't talking
about the actual abilities to create graphical windows
with one tool or the other. I was just saying that
PS is designed for console, not for GUI-level.
Tom Shelton
2009-10-30 05:57:35 UTC
Permalink
Raw Message
Post by mayayana
Post by Tom Shelton
Post by mayayana
It looks to me like MS is doing the same thing with
.Net. It's sandboxed, but on Windows there's API access
and unmanaged code.
Which you can't use from a browser app. See, .NET has
this thing called Code
Access Security (CAS). In the browser context that is
not allowed - unless the user
specifically goes in and alters policy settings.
You make a number of detailed points about how .Net
security works, but that doesn't mean it can't end up having
vulnerabilities. You say it's got protection in the browser,
yet Silverlight is .Net. Flash is also thought to be safe,
except when it isn't.
Of course there could be vulnerabilities discovered - just as there have been
in past Java runtimes. But, there are multiple layers of secruity to get
through, which usually renders any attack mostly theoretical. I'm not saying
it can't happen - just that it is very unlikely given the restrictions in
place.

The point though is you can not compare the security of ActiveX to that in
.NET. It is far and a away more secure.
Post by mayayana
So what I'm saying is that MS is taking the same route
they took with ActiveX: leveraging the Windows monopoly
to gain market share online and vice versa. And it's likely
to come back to haunt them.
Post by Tom Shelton
Post by mayayana
Thus my thought that some Dispatch interfaces might
make .Net rather attractive. :)
Make them you self. It's not hard.
You missed my point. The only usefulness I
see for .Net is if it's widely installed and has
COM interfaces. I don't want to use .Net. But
if it had COM interfaces I might find uses for
.Net in scripting. If I'm going to have to make
components myself, and then people can't use
my scripts without those components, then VB6
is the ideal tool for that. (I think even you would
agree with that.) It can easily create
dual-interface COM components that are well-
suited to Windows. To choose instead to write
wrappers for .Net would be ridiculous. I'd be
bringing in dependencies, limitations, bloat, and
a lot of extra work, for no reason at all.
Then don't do it. I don't care - but, I don't expect MS to release something
like that anytime soon.
Post by mayayana
Then again, you said "COM is becomming decreasingly
important". If you can say that the week after a
new version of Windows has come out -- just as
COM-centric as ever -- then... why do I bother? :)
Did I say COM was dead? No, I said decreasingly important. MS has long since
preaching the COM religion - but there are to many tools and existing
intefaces for it to be abandoned completely... But, they certainly aren't
encouraging it's use in their new tools are they?...
Post by mayayana
You also may have missed the point about
powershell vs scripting. I didn't mean to say that
VBScript is graphical. I meant that VBS - and the
Windows Script Host (WSH) - is designed for a GUI
system. DOS command line was for DOS. When
Windows came in with a GUI the WSH was provided
as a tool designed to work with a GUI system.
PowerShell is a return to console. I wasn't talking
about the actual abilities to create graphical windows
with one tool or the other. I was just saying that
PS is designed for console, not for GUI-level.
No, PS was designed as both a command line shell environment and a scripting
environment. I doubt there is much that you can do in VBS that can't be done
in PS. They are even including an IDE of sorts in PS2.
--
Tom Shelton
mayayana
2009-10-30 16:43:10 UTC
Permalink
Raw Message
Post by Tom Shelton
Post by mayayana
You also may have missed the point about
powershell vs scripting. I didn't mean to say that
VBScript is graphical. I meant that VBS - and the
Windows Script Host (WSH) - is designed for a GUI
system. DOS command line was for DOS. When
Windows came in with a GUI the WSH was provided
as a tool designed to work with a GUI system.
PowerShell is a return to console. I wasn't talking
about the actual abilities to create graphical windows
with one tool or the other. I was just saying that
PS is designed for console, not for GUI-level.
No, PS was designed as both a command line shell
environment and a scripting
environment. I doubt there is much that you can
do in VBS that can't be done
in PS. They are even including an IDE of sorts in PS2.
You've used PS and I've only researched it, so maybe
I've missed something, but what I see in the docs
and descriptions seems to point to console. There's
something called a ps1 file to store functions, but on
wikipedia that's described as a way to "persist code
between sessions". I assume that's console sessions.

This kind of discussion often gets confusing because
people use things for different reasons and often don't
differentiate between console and GUI scripting. (There's
a problem in the VBS newsgroup of people posting DOS
commands for VBS questions, for instance. :) And some
console people are anti-mouse people, with a chauvinist
attitude about console, which doesn't help matters.

What I mean by GUI scripting is code stored in a file
that can run an interactive program; a script especially
adapted to Windows GUI level. With VBS I can
have drag-drop functionality (GUI level), where something
is dropped onto a script, say, and the script can then
carry out various operations with GUI feedback - no
console needed. I can also write fullscale software
of a sort by writing HTAs. Are you saying that PS can
do all that? I could use PS to write a script-powered file
(a .ps1 file, maybe?) that someone can double-click --
or drop a file onto -- which could then essentially run
a .Net program, with fully functional .Net windows,
buttons, etc.? It would be a script-based .Net program?
And that program can access COM objects,
the Windows Shell, the Registry, file I/O, string and
binary file operations, etc.? And no command line
operations or console window would need to be a
part of that?

If that's the case then PS might be interesting
indeed. (Aside from the limitation of needing .Net
and only being pre-installed on Win7. That will be
a notable limitation for a long time to come,
outside of intranets where all of your target machines
are known and controlled. As it is now, I write a lot
a VBScript-based tools that can be used by nearly
anyone on Win98+ without any dependencies that
are not pre-installed.)
Tom Shelton
2009-10-30 16:52:59 UTC
Permalink
Raw Message
Post by mayayana
Post by Tom Shelton
Post by mayayana
You also may have missed the point about
powershell vs scripting. I didn't mean to say that
VBScript is graphical. I meant that VBS - and the
Windows Script Host (WSH) - is designed for a GUI
system. DOS command line was for DOS. When
Windows came in with a GUI the WSH was provided
as a tool designed to work with a GUI system.
PowerShell is a return to console. I wasn't talking
about the actual abilities to create graphical windows
with one tool or the other. I was just saying that
PS is designed for console, not for GUI-level.
No, PS was designed as both a command line shell
environment and a scripting
environment. I doubt there is much that you can
do in VBS that can't be done
in PS. They are even including an IDE of sorts in PS2.
You've used PS and I've only researched it, so maybe
I've missed something, but what I see in the docs
and descriptions seems to point to console. There's
something called a ps1 file to store functions, but on
wikipedia that's described as a way to "persist code
between sessions". I assume that's console sessions.
A ps1 file is a PowerShell script file. You were probably seeing references
to the a powershell profile, which is also a script :) It gets run when you
start a PS session... And yes, one function is to put commonly used functions
into your session so that they are avaialbe from the command line...

For instance, here is the portion of mine I use to set a custom linux like
prompt:

$global:CurrentUser = [System.Security.Principal.WindowsIdentity]::GetCurrent()
function Prompt
{
$host.ui.RawUI.WindowTitle = $(get-location)
write-host ($CurrentUser.Name) -nonewline -foregroundcolor Green
" $ "
}


I also set a bunch of environment variables, etc so that I can use ps as my VS
command prompt window. Basically, I took the bat file that gets run at the VS
command prompt, and converted it to ps and put it in my profile script.


Beyond that, you can create standalone ps scripts that you can run from the ps
console.
Post by mayayana
This kind of discussion often gets confusing because
people use things for different reasons and often don't
differentiate between console and GUI scripting. (There's
a problem in the VBS newsgroup of people posting DOS
commands for VBS questions, for instance. :) And some
console people are anti-mouse people, with a chauvinist
attitude about console, which doesn't help matters.
What I mean by GUI scripting is code stored in a file
that can run an interactive program
Ok... You can do that. If the program has a scriptable interface - I'm
assuming com because you are talking VBScript...

; a script especially
Post by mayayana
adapted to Windows GUI level. With VBS I can
have drag-drop functionality (GUI level), where something
is dropped onto a script, say, and the script can then
carry out various operations with GUI feedback - no
console needed. I can also write fullscale software
of a sort by writing HTAs. Are you saying that PS can
do all that? I could use PS to write a script-powered file
(a .ps1 file, maybe?) that someone can double-click --
or drop a file onto -- which could then essentially run
a .Net program, with fully functional .Net windows,
buttons, etc.? It would be a script-based .Net program?
And that program can access COM objects,
the Windows Shell, the Registry, file I/O, string and
binary file operations, etc.? And no command line
operations or console window would need to be a
part of that?
Given your description, I think you would say it ps is console oriented...
You can execute scripts from a shortcut or a scheduled task, etc - but, a
console window will open. You can get around this though by making a small
vbscript as the target and have it execute the ps script in a hidden console
window. You also can not directly launch a ps script file from explorer by
double clicking. This is by design to avoid a common attack vector. If you
doule click a ps script file, it will open in notepad :)

As for the rest, registry, com, file i/o, automation, etc, etc. Yes you can
do all of that. PS was designed to be a windows managment tool, on par with
the shell scripting environments that have been on *nix for years. And yes,
you can write UI's, though there are some limitations in ps v1 involving the
types of events you can handle using script blocks....
--
Tom Shelton
mayayana
2009-10-30 19:20:29 UTC
Permalink
Raw Message
Post by Tom Shelton
Post by mayayana
What I mean by GUI scripting is code stored in a file
that can run an interactive program
Ok... You can do that. If the program has a scriptable interface - I'm
assuming com because you are talking VBScript...
I don't mean automation. I mean the script IS
the program, operating with message windows,
FileOpen dialogs, etc. as an interactive *GUI-oriented*
program.
Post by Tom Shelton
As for the rest, registry, com, file i/o, automation,
etc, etc. Yes you can
do all of that. PS was designed to be a windows
managment tool, on par with
the shell scripting environments that have been
on *nix for years. And yes,
you can write UI's, though there are some
limitations in ps v1 involving the
types of events you can handle using script blocks....
That was my impression. An interesting tool for
sys. admins, but not of much value for people who
aren't operating in console mode.

I think of it as
two completely different kinds of tools. Console is
mainly interactive. GUI scripting is more like desktop
software programming:
One does a lot of coding now so that one
can just click buttons and drag/drop later. There's never
any work or coding or typing paths at execution time,
because that would defeat the purpose. It's taking
advantage of the luxury of GUI.

I find it odd that Microsoft is backtracking to
console-only scripting, which is really suited to
console OSs. I notice that you characterized an
Explorer connection as a security risk:

"You also can not directly launch a ps script file from explorer by
double clicking. This is by design to avoid a common attack vector. "

Maybe that was Microsoft's reasoning. Maybe it's
just part of the effort to reduce the options for
people to go fiddling with the system: providing
good tools for sys. admins while gradually removing
tools that operate more at the user level.
Tom Shelton
2009-10-30 18:39:10 UTC
Permalink
Raw Message
Post by mayayana
Post by Tom Shelton
Post by mayayana
What I mean by GUI scripting is code stored in a file
that can run an interactive program
Ok... You can do that. If the program has a scriptable interface - I'm
assuming com because you are talking VBScript...
I don't mean automation. I mean the script IS
the program, operating with message windows,
FileOpen dialogs, etc. as an interactive *GUI-oriented*
program.
Ok... And? You can do that - it just might have a console window open while
running (unless you cheat a little).
Post by mayayana
Post by Tom Shelton
As for the rest, registry, com, file i/o, automation,
etc, etc. Yes you can
do all of that. PS was designed to be a windows
managment tool, on par with
the shell scripting environments that have been
on *nix for years. And yes,
you can write UI's, though there are some
limitations in ps v1 involving the
types of events you can handle using script blocks....
That was my impression. An interesting tool for
sys. admins, but not of much value for people who
aren't operating in console mode.
I think of it as
two completely different kinds of tools. Console is
mainly interactive. GUI scripting is more like desktop
One does a lot of coding now so that one
can just click buttons and drag/drop later. There's never
any work or coding or typing paths at execution time,
because that would defeat the purpose. It's taking
advantage of the luxury of GUI.
I already told you, can do that in ps. You just create a shortcut that calls
powershell.exe and give it the script path as an argument.

Still, PS is an admin tool primarily. And a very good one at that.
Post by mayayana
I find it odd that Microsoft is backtracking to
console-only scripting, which is really suited to
console OSs.
It's not backtracking. The console is often easier to work with to admin things then
pointy-clickity type things. Windows has long been critizied for it's lack of
a decent shell and shell scripting environment. PS was created to address
that.

I like PS, but I'm not saying it invalidates tools like vbscript. In fact,
it's quite possible and common to host wsh languages inside of ps so that you
can run existing active scripting scripts... So, it gives the best of both
worlds really.
Post by mayayana
I notice that you characterized an
"You also can not directly launch a ps script file from explorer by
double clicking. This is by design to avoid a common attack vector. "
Yep.
Post by mayayana
Maybe that was Microsoft's reasoning. Maybe it's
just part of the effort to reduce the options for
people to go fiddling with the system: providing
good tools for sys. admins while gradually removing
tools that operate more at the user level.
No one is removing vbs. It's still there. It's just that ps, especially ps2
is much more suitable as an admin tool then vbs is. And it's about time
really.
--
Tom Shelton
mayayana
2009-11-21 15:43:02 UTC
Permalink
Raw Message
An interesting follow-up to the .Nxt/COM/ActiveX
discussion... this from the "Well, whaddayaknow" Dept.

http://www.theregister.co.uk/2009/11/20/silverlight_4_windows_bias/

It seems that MS intends to add COM component
functionality to Silverlight on Windows. Amazingly
they haven't learned their lesson with ActiveX in
IE. (Or maybe they have. IE might be a security
nightmare, but it's still the most popular browser.)

This development is also a reminder of two things:

1) Beware of Microsofties bearing cross-platform
claims. It won't happen. Not really.

2) Never assume that Microsoft's direction is
accurately portrayed by their marketing. (If one
reads the discussion below it's clear just how much
.Nxt people have been sold the idea that .Nxt is the
future and that COM -- even native code -- is
"yesterday's news".)
Post by Tom Shelton
Post by mayayana
Post by Tom Shelton
Post by mayayana
It looks to me like MS is doing the same thing with
.Net. It's sandboxed, but on Windows there's API access
and unmanaged code.
Which you can't use from a browser app. See, .NET has
this thing called Code
Access Security (CAS). In the browser context that is
not allowed - unless the user
specifically goes in and alters policy settings.
You make a number of detailed points about how .Net
security works, but that doesn't mean it can't end up having
vulnerabilities. You say it's got protection in the browser,
yet Silverlight is .Net. Flash is also thought to be safe,
except when it isn't.
Of course there could be vulnerabilities discovered - just as there have been
in past Java runtimes. But, there are multiple layers of secruity to get
through, which usually renders any attack mostly theoretical. I'm not saying
it can't happen - just that it is very unlikely given the restrictions in
place.
The point though is you can not compare the security of ActiveX to that in
.NET. It is far and a away more secure.
Post by mayayana
So what I'm saying is that MS is taking the same route
they took with ActiveX: leveraging the Windows monopoly
to gain market share online and vice versa. And it's likely
to come back to haunt them.
Post by Tom Shelton
Post by mayayana
Thus my thought that some Dispatch interfaces might
make .Net rather attractive. :)
Make them you self. It's not hard.
You missed my point. The only usefulness I
see for .Net is if it's widely installed and has
COM interfaces. I don't want to use .Net. But
if it had COM interfaces I might find uses for
.Net in scripting. If I'm going to have to make
components myself, and then people can't use
my scripts without those components, then VB6
is the ideal tool for that. (I think even you would
agree with that.) It can easily create
dual-interface COM components that are well-
suited to Windows. To choose instead to write
wrappers for .Net would be ridiculous. I'd be
bringing in dependencies, limitations, bloat, and
a lot of extra work, for no reason at all.
Then don't do it. I don't care - but, I don't expect MS to release something
like that anytime soon.
Post by mayayana
Then again, you said "COM is becomming decreasingly
important". If you can say that the week after a
new version of Windows has come out -- just as
COM-centric as ever -- then... why do I bother? :)
Did I say COM was dead? No, I said decreasingly important. MS has long since
preaching the COM religion - but there are to many tools and existing
intefaces for it to be abandoned completely... But, they certainly aren't
encouraging it's use in their new tools are they?...
Post by mayayana
You also may have missed the point about
powershell vs scripting. I didn't mean to say that
VBScript is graphical. I meant that VBS - and the
Windows Script Host (WSH) - is designed for a GUI
system. DOS command line was for DOS. When
Windows came in with a GUI the WSH was provided
as a tool designed to work with a GUI system.
PowerShell is a return to console. I wasn't talking
about the actual abilities to create graphical windows
with one tool or the other. I was just saying that
PS is designed for console, not for GUI-level.
No, PS was designed as both a command line shell environment and a scripting
environment. I doubt there is much that you can do in VBS that can't be done
in PS. They are even including an IDE of sorts in PS2.
--
Tom Shelton
Karl E. Peterson
2009-10-29 18:11:41 UTC
Permalink
Raw Message
Post by Tom Shelton
My powershell book even has a simple web server example...
Which book is that? I've sorta wanted to learn more about PowerShell, "one of these
days." :-)
--
.NET: It's About Trust!
http://vfred.mvps.org
Tom Shelton
2009-10-29 18:24:57 UTC
Permalink
Raw Message
Post by Karl E. Peterson
Post by Tom Shelton
My powershell book even has a simple web server example...
Which book is that? I've sorta wanted to learn more about PowerShell, "one of these
days." :-)
"Windows PowerShell In Action" by Bruce Payette. ISBN-10: 1-932394-90-7,
ISBN-13: 978-1-932394-90-0

HTH
--
Tom Shelton
Karl E. Peterson
2009-10-29 18:29:52 UTC
Permalink
Raw Message
Post by Tom Shelton
Post by Karl E. Peterson
Post by Tom Shelton
My powershell book even has a simple web server example...
Which book is that? I've sorta wanted to learn more about PowerShell, "one of
these days." :-)
"Windows PowerShell In Action" by Bruce Payette. ISBN-10: 1-932394-90-7,
ISBN-13: 978-1-932394-90-0
I'll take a look. Thanks...
--
.NET: It's About Trust!
http://vfred.mvps.org
Tom Shelton
2009-10-29 18:34:49 UTC
Permalink
Raw Message
Post by Karl E. Peterson
Post by Tom Shelton
Post by Karl E. Peterson
Post by Tom Shelton
My powershell book even has a simple web server example...
Which book is that? I've sorta wanted to learn more about PowerShell, "one of
these days." :-)
"Windows PowerShell In Action" by Bruce Payette. ISBN-10: 1-932394-90-7,
ISBN-13: 978-1-932394-90-0
I'll take a look. Thanks...
Your welcome. If you haven't looked at it yet - I warn you the syntax is very
perlish (which is probably why I like it). In fact, in the book it mentions
that when they were first designing PowerShell Perl was the target language...
--
Tom Shelton
Karl E. Peterson
2009-10-29 18:55:07 UTC
Permalink
Raw Message
Post by Tom Shelton
Post by Karl E. Peterson
Post by Tom Shelton
Post by Karl E. Peterson
Post by Tom Shelton
My powershell book even has a simple web server example...
Which book is that? I've sorta wanted to learn more about PowerShell, "one of
these days." :-)
"Windows PowerShell In Action" by Bruce Payette. ISBN-10: 1-932394-90-7,
ISBN-13: 978-1-932394-90-0
I'll take a look. Thanks...
Your welcome. If you haven't looked at it yet - I warn you the syntax is very
perlish (which is probably why I like it). In fact, in the book it mentions
that when they were first designing PowerShell Perl was the target language...
Hmmmm, I tend to go all love/hate on perl, myself, depending on the mood, phase of
the moon, etc. <g>
--
.NET: It's About Trust!
http://vfred.mvps.org
Kev Provance
2009-10-29 01:09:36 UTC
Permalink
Raw Message
"amdrit" <***@hotmail.com> wrote in message news:%***@TK2MSFTNGP02.phx.gbl...
| So you are suggesting that I am the only person that is using VB 6 and
.Net
| in this manner? Some VB 6 users may not use the Interop forum, no since
in
| limiting my exposure. But thanks for detracting from the subject at hand.

Based on that sassy reply, I think you are another .Nxt troll here to stir
up trouble. Oh look, McCarthy joined in as well. Yup. Suspicions
confirmed.

Go away, troll.
Bill McCarthy
2009-10-28 22:58:44 UTC
Permalink
Raw Message
Post by mayayana
You could
microsoft.public.dotnet.languages.vb
Why ? His question is about C# and VB6.

As usual, it'd be a lot better if you either helped the poster or simply
ignored the post.
Kev Provance
2009-10-29 01:11:17 UTC
Permalink
Raw Message
"Bill McCarthy" <***@localhost.com> wrote in message news:***@TK2MSFTNGP04.phx.gbl...
|
|
| "mayayana" <***@rcXXn.com> wrote in message
| news:***@TK2MSFTNGP02.phx.gbl...
|
| > You could
| > also post here:
| > microsoft.public.dotnet.languages.vb
| >
|
| Why ? His question is about C# and VB6.
|
| As usual, it'd be a lot better if you either helped the poster or simply
| ignored the post.

As usual, it would be helpful if you crawled off somewhere and died. The
interop NG is there for a reason. If he's getting no replies, then no one
knows, or cares. Why don't you fo there and check for questions dickface?
What? Because it would be in line with your goal of trolling to answer them
here? Yup. You're so transparent.
mayayana
2009-10-29 03:24:25 UTC
Permalink
Raw Message
Post by Bill McCarthy
Why ? His question is about C# and VB6.
Ah, yes. Sorry. I missed that. Now if you
would just move your discussion to interop,
dropping the VB group from your posts, then
all will be well.
Bill McCarthy
2009-10-28 23:03:37 UTC
Permalink
Raw Message
Hi amdrit,

Is this VB6 dll on the remote machine ? I'd package the VB6 dll with the C#
application using XCopy deployment. A manifest is created so as the VB6 app
is easily distributed side by side.
Failing that, create a simple test case and step through to where the error
is. ProcessMon (the newer version of FileMon) from the SysInternals pages on
the TechEd site will show you the file being looked for and also the
registry keys being accessed.
Post by amdrit
I have a C# assembly that makes reference to a VB 6 library. Durning
runtime, when I attempt to create an instance of my Vb 6 class object, I
receive a FileNotFoundException. I have no idea where to start figuring
this one out.
When I make refernce to the VB6 dll, C# creates the Interop wrapper for
me. That is the file that generates the FileNotFoundException. The C# dll
is loaded via MSTSC via the RDP virtual channels and that is the only
difference when referencing the VB 6 library.
I can create a simple windows forms application, reference my Vb 6
library, and it will execute fine.
What I am wondering is, do I need to put the interop wrapper somewhere
else for it to work as expected with my intended solution?
amdrit
2009-10-29 00:57:50 UTC
Permalink
Raw Message
Currently everything is on my development workstation, except for the
portion that lives on the the Terminal Server that activates the virtual
channel.

The virtual channel activates a C# assembly on the local machine. That C#
component references the Vb 6 DLL.

Calls to the VB 6 DLL works fine when accessed via a simple windows forms
application.

void button_click()
{
MyDll.MyClass myClass = new MyDll.MyClass();
myClass.Test();
}

Calls to creation of the VB 6 DLL fail when accessed via my solution's
workflow.

void DataRecieved(byte[] data)
{
MyDll.MyClass myClass = new MyDll.MyClass(); //<-- Code fails here
myClass.OnDataWrite += new DataWriteHandler(myClass_DataWrite);
myClass.ProcessData(data);
}

The error I receive is FileNotFound - Could not load file or assembly
'Interop.MyDLL, Version=6.0.0.0, Culture=neutral, PublicKeyToken=null' or
one of its dependencies. The system cannot find the file specified.

The DLL itself is registered in the registry and VB 6 calls to it or C#
calls to it work fine. I guess I don't know where this solution is looking
to find the Interop.MyDLL in my particular solution. Currently, all the C#
binaries and VB 6 binaries live in the same directory and are
registered/regasmed there. Also the Virtual Channel setup in the registry
points to this directory.

The only thing I can think of is that the actuall calling assembly should be
MSTSC and so perhaps the VB 6 binary needs to live in the %winsys%
directory. I am not sure on this.

Here is my trace output

'mstsc.exe' (Managed): Loaded
'C:\WINDOWS\assembly\GAC_32\mscorlib\2.0.0.0__b77a5c561934e089\mscorlib.dll',
Skipped loading symbols. Module is optimized and the debugger option 'Just
My Code' is enabled.
'mstsc.exe' (Managed): Loaded
'C:\WINDOWS\assembly\GAC_MSIL\System.Windows.Forms\2.0.0.0__b77a5c561934e089\System.Windows.Forms.dll',
Skipped loading symbols. Module is optimized and the debugger option 'Just
My Code' is enabled.
'mstsc.exe' (Managed): Loaded
'C:\WINDOWS\assembly\GAC_MSIL\System\2.0.0.0__b77a5c561934e089\System.dll',
Skipped loading symbols. Module is optimized and the debugger option 'Just
My Code' is enabled.
'mstsc.exe' (Managed): Loaded
'C:\WINDOWS\assembly\GAC_MSIL\System.Drawing\2.0.0.0__b03f5f7f11d50a3a\System.Drawing.dll',
Skipped loading symbols. Module is optimized and the debugger option 'Just
My Code' is enabled.
'mstsc.exe' (Managed): Loaded
'D:\Dev\prototypes\rdpvirtualchannels\chanclient.dll', Symbols loaded.
A first chance exception of type 'System.IO.FileNotFoundException' occurred
in chanclient.dll --> Here is my issue
'mstsc.exe' (Managed): Loaded
'C:\WINDOWS\assembly\GAC_MSIL\System.Configuration\2.0.0.0__b03f5f7f11d50a3a\System.Configuration.dll',
Skipped loading symbols. Module is optimized and the debugger option 'Just
My Code' is enabled.
'mstsc.exe' (Managed): Loaded
'C:\WINDOWS\assembly\GAC_MSIL\System.Xml\2.0.0.0__b77a5c561934e089\System.Xml.dll',
Skipped loading symbols. Module is optimized and the debugger option 'Just
My Code' is enabled.
'mstsc.exe' (Managed): Loaded
'C:\WINDOWS\assembly\GAC_MSIL\Microsoft.VisualStudio.Debugger.Runtime\9.0.0.0__b03f5f7f11d50a3a\Microsoft.VisualStudio.Debugger.Runtime.dll'

I realize not everyone deals with this aspect of development and my
situation may be rather unique and I am sure I overlooked something. I am
just hoping someone in the community has seen this or has an idea as to
where to look.

step through illustration:

launch mstsc, connect to the terminal server
launch application, click the "make it go" button
application opens a virtual channel for this session and issues a call
(obviously over simplified)
mstsc finds the corresponding virtual channel definition in the registry and
launches the corresponding dll.
corresponding dll opens the virtual channel on the client machine and
listens for data
corresponding dll loads vb 6 dll.to process incoming messages <-- this part
fails

Thanks in advance.
Post by Bill McCarthy
Hi amdrit,
Is this VB6 dll on the remote machine ? I'd package the VB6 dll with the
C# application using XCopy deployment. A manifest is created so as the VB6
app is easily distributed side by side.
Failing that, create a simple test case and step through to where the
error is. ProcessMon (the newer version of FileMon) from the SysInternals
pages on the TechEd site will show you the file being looked for and also
the registry keys being accessed.
Kev Provance
2009-10-29 01:13:13 UTC
Permalink
Raw Message
"amdrit" <***@hotmail.com> wrote in message news:***@TK2MSFTNGP04.phx.gbl...
| Currently everything is on my development workstation, except for the
| portion that lives on the the Terminal Server that activates the virtual
| channel.
|

TL;DR

This is a VB6 or lower group. C# or anything .Nxt has no place here. ANY
implementation that requires .Nxt belong in it's respective group. I would
repost your trolling there where I'm sure your buttboy Bill will be more
than happy to continue ignoring you.
Bill McCarthy
2009-10-29 01:16:42 UTC
Permalink
Raw Message
Hi amdrit,

Fuslogvw will show you managed assembly paths that are probed. If the error
is there, then putting your assembly in the GAC will likely solve it (or
look at what paths are probed).
Likewise for the VB6 dll use Process Monitor:
http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx

You should be able to identify the VB6 MyClass CLSID and detect the registry
reading for it and then note any file not found errors shortly there after.
%winsys% may fix it.

Oh also make sure your .NET application is compiled as x86, not as Any CPU.
If your .NEt code runs as x64 the VB6 dll won't be loaded as it can't run as
x64.
Post by amdrit
Currently everything is on my development workstation, except for the
portion that lives on the the Terminal Server that activates the virtual
channel.
The virtual channel activates a C# assembly on the local machine. That C#
component references the Vb 6 DLL.
Calls to the VB 6 DLL works fine when accessed via a simple windows forms
application.
void button_click()
{
MyDll.MyClass myClass = new MyDll.MyClass();
myClass.Test();
}
Calls to creation of the VB 6 DLL fail when accessed via my solution's
workflow.
void DataRecieved(byte[] data)
{
MyDll.MyClass myClass = new MyDll.MyClass(); //<-- Code fails here
myClass.OnDataWrite += new DataWriteHandler(myClass_DataWrite);
myClass.ProcessData(data);
}
The error I receive is FileNotFound - Could not load file or assembly
'Interop.MyDLL, Version=6.0.0.0, Culture=neutral, PublicKeyToken=null' or
one of its dependencies. The system cannot find the file specified.
The DLL itself is registered in the registry and VB 6 calls to it or C#
calls to it work fine. I guess I don't know where this solution is
looking to find the Interop.MyDLL in my particular solution. Currently,
all the C# binaries and VB 6 binaries live in the same directory and are
registered/regasmed there. Also the Virtual Channel setup in the registry
points to this directory.
The only thing I can think of is that the actuall calling assembly should
be MSTSC and so perhaps the VB 6 binary needs to live in the %winsys%
directory. I am not sure on this.
Here is my trace output
'mstsc.exe' (Managed): Loaded
'C:\WINDOWS\assembly\GAC_32\mscorlib\2.0.0.0__b77a5c561934e089\mscorlib.dll',
Skipped loading symbols. Module is optimized and the debugger option 'Just
My Code' is enabled.
'mstsc.exe' (Managed): Loaded
'C:\WINDOWS\assembly\GAC_MSIL\System.Windows.Forms\2.0.0.0__b77a5c561934e089\System.Windows.Forms.dll',
Skipped loading symbols. Module is optimized and the debugger option 'Just
My Code' is enabled.
'mstsc.exe' (Managed): Loaded
'C:\WINDOWS\assembly\GAC_MSIL\System\2.0.0.0__b77a5c561934e089\System.dll',
Skipped loading symbols. Module is optimized and the debugger option 'Just
My Code' is enabled.
'mstsc.exe' (Managed): Loaded
'C:\WINDOWS\assembly\GAC_MSIL\System.Drawing\2.0.0.0__b03f5f7f11d50a3a\System.Drawing.dll',
Skipped loading symbols. Module is optimized and the debugger option 'Just
My Code' is enabled.
'mstsc.exe' (Managed): Loaded
'D:\Dev\prototypes\rdpvirtualchannels\chanclient.dll', Symbols loaded.
A first chance exception of type 'System.IO.FileNotFoundException'
occurred in chanclient.dll --> Here is my issue
'mstsc.exe' (Managed): Loaded
'C:\WINDOWS\assembly\GAC_MSIL\System.Configuration\2.0.0.0__b03f5f7f11d50a3a\System.Configuration.dll',
Skipped loading symbols. Module is optimized and the debugger option 'Just
My Code' is enabled.
'mstsc.exe' (Managed): Loaded
'C:\WINDOWS\assembly\GAC_MSIL\System.Xml\2.0.0.0__b77a5c561934e089\System.Xml.dll',
Skipped loading symbols. Module is optimized and the debugger option 'Just
My Code' is enabled.
'mstsc.exe' (Managed): Loaded
'C:\WINDOWS\assembly\GAC_MSIL\Microsoft.VisualStudio.Debugger.Runtime\9.0.0.0__b03f5f7f11d50a3a\Microsoft.VisualStudio.Debugger.Runtime.dll'
I realize not everyone deals with this aspect of development and my
situation may be rather unique and I am sure I overlooked something. I am
just hoping someone in the community has seen this or has an idea as to
where to look.
launch mstsc, connect to the terminal server
launch application, click the "make it go" button
application opens a virtual channel for this session and issues a call
(obviously over simplified)
mstsc finds the corresponding virtual channel definition in the registry
and launches the corresponding dll.
corresponding dll opens the virtual channel on the client machine and
listens for data
corresponding dll loads vb 6 dll.to process incoming messages <-- this
part fails
Thanks in advance.
Post by Bill McCarthy
Hi amdrit,
Is this VB6 dll on the remote machine ? I'd package the VB6 dll with the
C# application using XCopy deployment. A manifest is created so as the
VB6 app is easily distributed side by side.
Failing that, create a simple test case and step through to where the
error is. ProcessMon (the newer version of FileMon) from the SysInternals
pages on the TechEd site will show you the file being looked for and also
the registry keys being accessed.
amdrit
2009-10-29 16:38:40 UTC
Permalink
Raw Message
The simple answer was in TLBIMP.EXE. All I needed to do was sign the
interop assembly and then add it to the GAC.

Thanks
Loading...