FileNotFoundException Loading ActiveX dll
amdrit
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
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.
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. But thanks for detracting from the subject at hand.
"mayayana" <mayaX...@rcXXn.com> wrote in message
news:OguHaxAW...@TK2MSFTNGP02.phx.gbl...
mayayana
> 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
> I'm not suggesting you're the only person using VB6
> with interop.
LOL.
Of course not!
May be... a couple of dozens?
Bill McCarthy
"mayayana" <mayaX...@rcXXn.com> wrote in message
news:OguHaxAW...@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.
Bill McCarthy
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" <amd...@hotmail.com> wrote in message
news:#ycUHnAW...@TK2MSFTNGP05.phx.gbl...
amdrit
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.
"Bill McCarthy" <bi...@localhost.com> wrote in message
news:%23aSpuNC...@TK2MSFTNGP04.phx.gbl...
Kev Provance
| 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.
Kev Provance
"Bill McCarthy" <bi...@localhost.com> wrote in message
news:OZkCuNCW...@TK2MSFTNGP04.phx.gbl...
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.
Kev Provance
| 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
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.
"amdrit" <amd...@hotmail.com> wrote in message
news:uvqwmLDW...@TK2MSFTNGP04.phx.gbl...
mayayana
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
>>
>> > 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.
> 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.
> -- 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.
> 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
> Dude, it's almost childs play to expose .NET functionality to COM.
Interop
> goes both ways.
>
.......
> 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
>
>
> Interop
>> goes both ways.
>>
> .......
>> 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.
>
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?
> 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...
> 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
> > 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. :)
amdrit
interop assembly and then add it to the GAC.
Thanks
Tom Shelton
>
>> > 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.
>
> 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.
> 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.
> 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
> 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.
> 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...
> 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
> 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
Karl E. Peterson
> .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?
Tom Shelton
> Tom Shelton wrote:
>> 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
I'll take a look. Thanks...
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
Not much. Nice anecdote. (And, btw, ASP is .NET-free ;-)
Tom Shelton
> Tom Shelton wrote:
>> On 2009-10-29, Karl E. Peterson <ka...@exmvps.org> wrote:
>>> Tom Shelton wrote:
>>>> 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
Tom Shelton
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
>>> 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>
> 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.
Karl E. Peterson
> On 2009-10-29, Karl E. Peterson <ka...@exmvps.org> wrote:
>> Tom Shelton wrote:
>>> On 2009-10-29, Karl E. Peterson <ka...@exmvps.org> wrote:
>>>> Tom Shelton wrote:
>>>>> 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>
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>
>
>> 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.
> 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
> 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.
>> 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. :-)
amdrit
To assume all the developers that I was looking to get a response from only
monitored the interop forums and that they never visit the
vb.generaldiscussion forum is simply ludicrous. To assume that there is no
cross platform exposure with VB 6 developers is foolish.
This post was made to both the interop group and the general discussion
group. I don't suppose that all developers are as close minded about
someone looking for assistance, a point I think is lost on you.
Certainly the issue wasn't directly related to the vb component, but since
the issue did involve the interop piece - I am sure other vb developers have
encountered my problem and would be able to offer advice on what to do.
But that is what it comes down too isn't it, guidance and advice? Neither
you nor mayayana have looked outside your own little world long enough to
actually be able to offer any help. Feeling threatened by your inadequacies
and seeing the trip word ".Net", it's time to flame the insufferable
antagonist and set his house in order for him. It is so pathetic that you
cannot accept that .Net is here and people are using it and worse yet, cross
the bloodlines by mixing your precious VB 6 world with the tainted brand.
I didn't come here stating .Net is far superior to the legacy VB 6. I asked
a question, a simple question that folks here in this group as well as the
other may have advice for. Personally, I don't care about the war against
.Net. Both products keep me gainfully employed. I've already resigned
myself to covert my personal VB 6 code to .Net just so I have it for either
need. If VB 6 gets a facelift and continued support, I am good to go.
However, while .Net lives and breaths and people are paying me to solve
their problems on that platform, I am set. I don't feel threatened when
someone asks a question that is a bit outside the box because I can't see
the relevance to the forum. If I have something to offer to a post, I offer
it. I don't just let the 2 year old in me run loose.
Making a personal attack against me just shows that you are both idiots and
perhaps haven't gotten much past an over simplified hello world application.
Personally, I don't care if you've actually written a millions lines of code
in your life. I find you both short sighted, narrow minded, egotistical and
elitist - elitist, I might add, to a cause neither of you are doing anything
about to correct, rather just foaming at the mouth so you can make
yourselves think you are even in the same league (albeit like the Lions are
to the Steelers) as the likes of Karl Peterson.
Looking over the past 9 years of posts on the VB forums, you can see a
definite downturn in quality of posts and responses, forum acceptance of
posters, and the overall number of posts.
So, instead of spewing your intolerance all over these forums. Get your
pink mohawk wearing ninja undead warlock back on his high horse, head on
over to the deadmines and camp some noob Alliance toons - the rush should be
about the same. You can always QQ in trade chat when you get pwnd by three
level ten nelf hunters.
Kev Provance
The fact that you would waste so much time and space defending yourself just
further confirms what I already knew.
"amdrit" <amd...@hotmail.com> wrote in message
news:%23b9NYDO...@TK2MSFTNGP05.phx.gbl...
mayayana
> guidance and advice? Neither
> you nor mayayana have looked outside
> your own little world long enough to
> actually be able to offer any help.
This isn't a war or a philosophical discussion.
It's very simple. This group is for VB6 and
lower, which has very little in common with .Net.
You might also get answers about VBA or VBScript
here, but it's a matter of common courtesy not
to ask questions in the wrong group. Do you
feel that common courtesy doesn't apply to you?
When you have a question about the VB part
of your project then, by all means, post it here.
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.
> > 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
>
>> > .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.
> 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.
>
>> > 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.
>
> 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?...
> 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
> > 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
>
>> > 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.
> 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
> 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
> > 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.
>
> 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
>> > 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).
>>
>> 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 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.
>
> 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.
> 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. "
>
Yep.
> 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
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".)