.exe throws exception from local, but not network drive

[frostalicious]

Used VB.NET (on my client PC) to convert VB6 executable
to .NET executable. Placed the .exe file on a network drive
on my server. From client, ran .NET Wizards "Trust an
Assembly" to make the .exe (on the network drive, on the
server) "Full Trust." From the client, double-click on the
..exe (on the network drive, on the server) and it runs fine.

So far, so good, but...

On the server, where I've installed not VB.NET but .NET
Framework 1.1, ran Microsoft .NET Framework 1.1 Wizards
"Trust an Assembly" to make the .exe (on the local hard
drive of the server, not a network drive) "Full Trust," which
sticks, but when I double-click on the .exe (on the server,
on the local hard drive) CLR Debugging Services gives
"Application has generated an exception that could not
be handled." Any advice on how to debug this, from the
server, where VB.NET is not installed, would be appreciated.

I suspect the exception is System.Security.SecurityException
but don't know where to put Try/Catch/End code, as the
exception is thrown before the form loads, and don't know
how to invoke the JIT debugger on the server.

BTW Server is Win2K Pro; client is XP Home.
Any suggestions? I'm new to .NET and haven't got .NET
security figured out (as if you couldn't tell.) The VB6 version
of the .exe ran fine, wherever I put it, local hard drive or network
drive. The application uses File System Object, if that's a clue.

-- frosty

[Crirus]

Have enough rights on that server? Try with an admin account to run the .exe

--
Ceers,
Crirus

------------------------------
If work were a good thing, the boss would take it all from you

------------------------------

"frostalicious" <fr*****@nospam.com> wrote in message
news:vr************@corp.supernews.com...

Used VB.NET (on my client PC) to convert VB6 executable
to .NET executable. Placed the .exe file on a network drive
on my server. From client, ran .NET Wizards "Trust an
Assembly" to make the .exe (on the network drive, on the
server) "Full Trust." From the client, double-click on the
.exe (on the network drive, on the server) and it runs fine.

So far, so good, but...

On the server, where I've installed not VB.NET but .NET
Framework 1.1, ran Microsoft .NET Framework 1.1 Wizards
"Trust an Assembly" to make the .exe (on the local hard
drive of the server, not a network drive) "Full Trust," which
sticks, but when I double-click on the .exe (on the server,
on the local hard drive) CLR Debugging Services gives
"Application has generated an exception that could not
be handled." Any advice on how to debug this, from the
server, where VB.NET is not installed, would be appreciated.

I suspect the exception is System.Security.SecurityException
but don't know where to put Try/Catch/End code, as the
exception is thrown before the form loads, and don't know
how to invoke the JIT debugger on the server.

BTW Server is Win2K Pro; client is XP Home.
Any suggestions? I'm new to .NET and haven't got .NET
security figured out (as if you couldn't tell.) The VB6 version
of the .exe ran fine, wherever I put it, local hard drive or network
drive. The application uses File System Object, if that's a clue.

-- frosty

[frostalicious]

> "frostalicious" <fr*****@nospam.com> wrote in message

news:vr************@corp.supernews.com...

Used VB.NET (on my client PC) to convert VB6 executable
to .NET executable. Placed the .exe file on a network drive
on my server. From client, ran .NET Wizards "Trust an
Assembly" to make the .exe (on the network drive, on the
server) "Full Trust." From the client, double-click on the
.exe (on the network drive, on the server) and it runs fine.

So far, so good, but...

On the server, where I've installed not VB.NET but .NET
Framework 1.1, ran Microsoft .NET Framework 1.1 Wizards
"Trust an Assembly" to make the .exe (on the local hard
drive of the server, not a network drive) "Full Trust," which
sticks, but when I double-click on the .exe (on the server,
on the local hard drive) CLR Debugging Services gives
"Application has generated an exception that could not
be handled." Any advice on how to debug this, from the
server, where VB.NET is not installed, would be appreciated.

I suspect the exception is System.Security.SecurityException
but don't know where to put Try/Catch/End code, as the
exception is thrown before the form loads, and don't know
how to invoke the JIT debugger on the server.

BTW Server is Win2K Pro; client is XP Home.
Any suggestions? I'm new to .NET and haven't got .NET
security figured out (as if you couldn't tell.) The VB6 version
of the .exe ran fine, wherever I put it, local hard drive or network
drive. The application uses File System Object, if that's a clue.

-- frosty

Crirus wrote: Have enough rights on that server? Try with an admin account to run
the .exe

------------------------------
If work were a good thing, the boss would take it all from you

------------------------------

Thanks, but that was not the problem. Turns out the exception had
nothing to do with System.Security.SecurityException. By copying
DLL's from the client to the server, was able to get enough of the
debugger info, in a command prompt box, to determine it was another
missing DLL, namely Microsoft.VisualBasic.Compatibility.dll and when
I copied that DLL to the server, my app started to work.

I'm sure there's a better way to assure the dll in question gets distributed
with the .exe that is my app. Anybody know how this is supposed to
be done? Can it be done in VB.NET or do I need VS.NET?

-- frosty

[Jay B. Harlow [MVP - Outlook]]

frostalicious,

I'm sure there's a better way to assure the dll in question gets distributed with the .exe that is my app. Anybody know how this is supposed to
be done? Can it be done in VB.NET or do I need VS.NET?
The Microsoft.VisualBasic.Compatibility.dll is not included with the
framework, you need to install it yourself.

My first advice is to avoid the Compatibility DLL if at all possible. If
that is not an option, then you may want to consider a Setup project to
ensure that all the components get installed, in the correct location.

Hope this helps
Jay
"frostalicious" <fr*****@nospam.com> wrote in message
news:vr************@corp.supernews.com...

"frostalicious" <fr*****@nospam.com> wrote in message
news:vr************@corp.supernews.com...

Used VB.NET (on my client PC) to convert VB6 executable
to .NET executable. Placed the .exe file on a network drive
on my server. From client, ran .NET Wizards "Trust an
Assembly" to make the .exe (on the network drive, on the
server) "Full Trust." From the client, double-click on the
.exe (on the network drive, on the server) and it runs fine.

So far, so good, but...

On the server, where I've installed not VB.NET but .NET
Framework 1.1, ran Microsoft .NET Framework 1.1 Wizards
"Trust an Assembly" to make the .exe (on the local hard
drive of the server, not a network drive) "Full Trust," which
sticks, but when I double-click on the .exe (on the server,
on the local hard drive) CLR Debugging Services gives
"Application has generated an exception that could not
be handled." Any advice on how to debug this, from the
server, where VB.NET is not installed, would be appreciated.

I suspect the exception is System.Security.SecurityException
but don't know where to put Try/Catch/End code, as the
exception is thrown before the form loads, and don't know
how to invoke the JIT debugger on the server.

BTW Server is Win2K Pro; client is XP Home.
Any suggestions? I'm new to .NET and haven't got .NET
security figured out (as if you couldn't tell.) The VB6 version
of the .exe ran fine, wherever I put it, local hard drive or network
drive. The application uses File System Object, if that's a clue.

-- frosty

Crirus wrote:

Have enough rights on that server? Try with an admin account to run
the .exe

------------------------------
If work were a good thing, the boss would take it all from you

------------------------------

Thanks, but that was not the problem. Turns out the exception had
nothing to do with System.Security.SecurityException. By copying
DLL's from the client to the server, was able to get enough of the
debugger info, in a command prompt box, to determine it was another
missing DLL, namely Microsoft.VisualBasic.Compatibility.dll and when
I copied that DLL to the server, my app started to work.

I'm sure there's a better way to assure the dll in question gets

distributed with the .exe that is my app. Anybody know how this is supposed to
be done? Can it be done in VB.NET or do I need VS.NET?

-- frosty

[frostalicious]

I would like to insure that all the components get installed, in the
correct location, yes. Could you elaborate on "consider a Setup
project" for me? I would also like to run the .exe on any system
with .net framework 1.1 installed, so if the compatibility dll is not
part of that setup (and it's not) then running the .exe without the
need for the compatibility dll would be preferred. Another thing
I don't know how to do. We are very much on the same page,
as far as strategy (which is encouraging to me!) but I need help
with tactics. I could live with sending each user a .exe and the
..dll file, but it's just so... tacky. And, presumably, unnecessary.

-- frosty

Jay B. Harlow [MVP - Outlook] wrote:

frostalicious,

I'm sure there's a better way to assure the dll in question gets
distributed with the .exe that is my app. Anybody know how this is
supposed to be done? Can it be done in VB.NET or do I need VS.NET?

The Microsoft.VisualBasic.Compatibility.dll is not included with the
framework, you need to install it yourself.

My first advice is to avoid the Compatibility DLL if at all possible.
If that is not an option, then you may want to consider a Setup
project to ensure that all the components get installed, in the
correct location.

Hope this helps
Jay
"frostalicious" <fr*****@nospam.com> wrote in message
news:vr************@corp.supernews.com...

"frostalicious" <fr*****@nospam.com> wrote in message
news:vr************@corp.supernews.com...
Used VB.NET (on my client PC) to convert VB6 executable
to .NET executable. Placed the .exe file on a network drive
on my server. From client, ran .NET Wizards "Trust an
Assembly" to make the .exe (on the network drive, on the
server) "Full Trust." From the client, double-click on the
.exe (on the network drive, on the server) and it runs fine.

So far, so good, but...

On the server, where I've installed not VB.NET but .NET
Framework 1.1, ran Microsoft .NET Framework 1.1 Wizards
"Trust an Assembly" to make the .exe (on the local hard
drive of the server, not a network drive) "Full Trust," which
sticks, but when I double-click on the .exe (on the server,
on the local hard drive) CLR Debugging Services gives
"Application has generated an exception that could not
be handled." Any advice on how to debug this, from the
server, where VB.NET is not installed, would be appreciated.

I suspect the exception is System.Security.SecurityException
but don't know where to put Try/Catch/End code, as the
exception is thrown before the form loads, and don't know
how to invoke the JIT debugger on the server.

BTW Server is Win2K Pro; client is XP Home.
Any suggestions? I'm new to .NET and haven't got .NET
security figured out (as if you couldn't tell.) The VB6 version
of the .exe ran fine, wherever I put it, local hard drive or
network drive. The application uses File System Object, if that's
a clue.

-- frosty

Crirus wrote:

Have enough rights on that server? Try with an admin account to run
the .exe

------------------------------
If work were a good thing, the boss would take it all from you

------------------------------

Thanks, but that was not the problem. Turns out the exception had
nothing to do with System.Security.SecurityException. By copying
DLL's from the client to the server, was able to get enough of the
debugger info, in a command prompt box, to determine it was another
missing DLL, namely Microsoft.VisualBasic.Compatibility.dll and when
I copied that DLL to the server, my app started to work.

I'm sure there's a better way to assure the dll in question gets
distributed with the .exe that is my app. Anybody know how this is
supposed to be done? Can it be done in VB.NET or do I need VS.NET?

-- frosty

[Phil Wilson]

The documentation says about that DLL, article 318833.
"Note: These files are included with Microsoft Visual Basic .NET to assist with
the upgrade process. They are not intended for use in new project development. "

You should post what functionality is in there that you're using and see if you
can use something else instead. I've seen people using it because it has a
folder browser, but there is one of these in the 1.1 framework (there wasn't in
1.0).
--
Phil Wilson [MVP Windows Installer]
----
"frostalicious" <fr*****@nospam.com> wrote in message
news:vr************@corp.supernews.com...

I would like to insure that all the components get installed, in the
correct location, yes. Could you elaborate on "consider a Setup
project" for me? I would also like to run the .exe on any system
with .net framework 1.1 installed, so if the compatibility dll is not
part of that setup (and it's not) then running the .exe without the
need for the compatibility dll would be preferred. Another thing
I don't know how to do. We are very much on the same page,
as far as strategy (which is encouraging to me!) but I need help
with tactics. I could live with sending each user a .exe and the
.dll file, but it's just so... tacky. And, presumably, unnecessary.

-- frosty

Jay B. Harlow [MVP - Outlook] wrote:

frostalicious,

I'm sure there's a better way to assure the dll in question gets
distributed with the .exe that is my app. Anybody know how this is
supposed to be done? Can it be done in VB.NET or do I need VS.NET?

The Microsoft.VisualBasic.Compatibility.dll is not included with the
framework, you need to install it yourself.

My first advice is to avoid the Compatibility DLL if at all possible.
If that is not an option, then you may want to consider a Setup
project to ensure that all the components get installed, in the
correct location.

Hope this helps
Jay
"frostalicious" <fr*****@nospam.com> wrote in message
news:vr************@corp.supernews.com...

"frostalicious" <fr*****@nospam.com> wrote in message
news:vr************@corp.supernews.com...
> Used VB.NET (on my client PC) to convert VB6 executable
> to .NET executable. Placed the .exe file on a network drive
> on my server. From client, ran .NET Wizards "Trust an
> Assembly" to make the .exe (on the network drive, on the
> server) "Full Trust." From the client, double-click on the
> .exe (on the network drive, on the server) and it runs fine.
>
> So far, so good, but...
>
> On the server, where I've installed not VB.NET but .NET
> Framework 1.1, ran Microsoft .NET Framework 1.1 Wizards
> "Trust an Assembly" to make the .exe (on the local hard
> drive of the server, not a network drive) "Full Trust," which
> sticks, but when I double-click on the .exe (on the server,
> on the local hard drive) CLR Debugging Services gives
> "Application has generated an exception that could not
> be handled." Any advice on how to debug this, from the
> server, where VB.NET is not installed, would be appreciated.
>
> I suspect the exception is System.Security.SecurityException
> but don't know where to put Try/Catch/End code, as the
> exception is thrown before the form loads, and don't know
> how to invoke the JIT debugger on the server.
>
> BTW Server is Win2K Pro; client is XP Home.
> Any suggestions? I'm new to .NET and haven't got .NET
> security figured out (as if you couldn't tell.) The VB6 version
> of the .exe ran fine, wherever I put it, local hard drive or
> network drive. The application uses File System Object, if that's
> a clue.
>
> -- frosty

Crirus wrote:
Have enough rights on that server? Try with an admin account to run
the .exe

------------------------------
If work were a good thing, the boss would take it all from you

------------------------------

Thanks, but that was not the problem. Turns out the exception had
nothing to do with System.Security.SecurityException. By copying
DLL's from the client to the server, was able to get enough of the
debugger info, in a command prompt box, to determine it was another
missing DLL, namely Microsoft.VisualBasic.Compatibility.dll and when
I copied that DLL to the server, my app started to work.

I'm sure there's a better way to assure the dll in question gets
distributed with the .exe that is my app. Anybody know how this is
supposed to be done? Can it be done in VB.NET or do I need VS.NET?

-- frosty

[frostalicious]

I'm using SendKeys:

Assembly Microsoft.VisualBasic.Compatibility
C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\Micro soft.VisualBasic.Compatibi
lity.dll
Namespace Microsoft.VisualBasic.Compatibility.VB6
Member of: Microsoft.VisualBasic.Compatibility
Public Module Support
Member of: Microsoft.VisualBasic.Compatibility.VB6
Public Sub SendKeys(ByVal Keys As String, Optional ByVal Wait As
Boolean = False)
Member of: Microsoft.VisualBasic.Compatibility.VB6.Support

-- frosty

Phil Wilson wrote:

The documentation says about that DLL, article 318833.
"Note: These files are included with Microsoft Visual Basic .NET to
assist with the upgrade process. They are not intended for use in new
project development. "

You should post what functionality is in there that you're using and
see if you can use something else instead. I've seen people using it
because it has a folder browser, but there is one of these in the 1.1
framework (there wasn't in 1.0).

I would like to insure that all the components get installed, in the
correct location, yes. Could you elaborate on "consider a Setup
project" for me? I would also like to run the .exe on any system
with .net framework 1.1 installed, so if the compatibility dll is not
part of that setup (and it's not) then running the .exe without the
need for the compatibility dll would be preferred. Another thing
I don't know how to do. We are very much on the same page,
as far as strategy (which is encouraging to me!) but I need help
with tactics. I could live with sending each user a .exe and the
.dll file, but it's just so... tacky. And, presumably, unnecessary.

-- frosty

Jay B. Harlow [MVP - Outlook] wrote:

frostalicious,
I'm sure there's a better way to assure the dll in question gets
distributed with the .exe that is my app. Anybody know how this is
supposed to be done? Can it be done in VB.NET or do I need VS.NET?

The Microsoft.VisualBasic.Compatibility.dll is not included with the
framework, you need to install it yourself.

My first advice is to avoid the Compatibility DLL if at all
possible. If that is not an option, then you may want to consider a
Setup project to ensure that all the components get installed, in
the correct location.

Hope this helps
Jay
[snip] [It] was another
missing DLL, namely Microsoft.VisualBasic.Compatibility.dll and
when I copied that DLL to the server, my app started to work.

[Eric Cadwell]

> I'm using SendKeys:

There is a System.Windows.Forms.SendKeys class.

HTH;
Eric Cadwell
http://www.origincontrols.com

[frostalicious]

>> I'm using SendKeys:

Eric Cadwell wrote:

There is a System.Windows.Forms.SendKeys class.

HTH;
Eric Cadwell
http://www.origincontrols.com

Turns out that's the only SendKeys I'm using.

How do I find what piece(s) of the VB compatibility
DLL is (are) really being used, then?

-- frosty

[Jay B. Harlow [MVP - Outlook]]

frostalicious,
I normally remove the imports looking for errors, then I remove the
reference looking for errors.

As I remove one of the above if there are a handful of errors I take care of
them as I go, if there a numerous errors I leave them and put the item back.

Hope this helps
Jay

"frostalicious" <fr*****@nospam.com> wrote in message
news:vr************@corp.supernews.com...

I'm using SendKeys:

Eric Cadwell wrote:

There is a System.Windows.Forms.SendKeys class.

HTH;
Eric Cadwell
http://www.origincontrols.com

Turns out that's the only SendKeys I'm using.

How do I find what piece(s) of the VB compatibility
DLL is (are) really being used, then?

-- frosty

[frostalicious]

I did remove the reference, and the errors are LabelArray
and TextBoxArray, which I think I can fix. How do I remove
the import?

-- jet

Jay B. Harlow [MVP - Outlook] wrote:

frostalicious,
I normally remove the imports looking for errors, then I remove the
reference looking for errors.

As I remove one of the above if there are a handful of errors I take
care of them as I go, if there a numerous errors I leave them and put
the item back.

Hope this helps
Jay

"frostalicious" <fr*****@nospam.com> wrote in message
news:vr************@corp.supernews.com...

I'm using SendKeys:

Eric Cadwell wrote:

There is a System.Windows.Forms.SendKeys class.

HTH;
Eric Cadwell
http://www.origincontrols.com

Turns out that's the only SendKeys I'm using.

How do I find what piece(s) of the VB compatibility
DLL is (are) really being used, then?

-- frosty

[frostalicious]

OK, in AssemblyInfo.vb I see the following:
Imports System.Reflection
Imports System.Runtime.CompilerServices
Imports System.Runtime.InteropServices

Recognize the third one as a DLL; don't know about
the first two. Looks like the VB compatibility is already
gone, maybe from when I removed the reference.

Should I remove these three, as well?

-- frosty

Jay B. Harlow [MVP - Outlook] wrote:

frostalicious,
I normally remove the imports looking for errors, then I remove the
reference looking for errors.

As I remove one of the above if there are a handful of errors I take
care of them as I go, if there a numerous errors I leave them and put
the item back.

Hope this helps
Jay

"frostalicious" <fr*****@nospam.com> wrote in message
news:vr************@corp.supernews.com...

I'm using SendKeys:

Eric Cadwell wrote:

There is a System.Windows.Forms.SendKeys class.

HTH;
Eric Cadwell
http://www.origincontrols.com

Turns out that's the only SendKeys I'm using.

How do I find what piece(s) of the VB compatibility
DLL is (are) really being used, then?

-- frosty

[Jay B. Harlow [MVP - Outlook]]

frostalicious,
When I say "remove the imports" I am referring to any import statements that
refer to either Microsoft.VisualBasic.Compatiblity or
Microsoft.VisualBasic.Compatiblity.VB6. As those are the two namespaces
exposed by the Microsoft.VisualBasic.Compatiblity assembly. If you are
importing those two namespaces there is a chance you are using objects from
the namespace, hence an object from the assembly.

Hope this helps
Jay

"frostalicious" <fr*****@nospam.com> wrote in message
news:vr************@corp.supernews.com...

I did remove the reference, and the errors are LabelArray
and TextBoxArray, which I think I can fix. How do I remove
the import?

-- jet

Jay B. Harlow [MVP - Outlook] wrote:

frostalicious,
I normally remove the imports looking for errors, then I remove the
reference looking for errors.

As I remove one of the above if there are a handful of errors I take
care of them as I go, if there a numerous errors I leave them and put
the item back.

Hope this helps
Jay

"frostalicious" <fr*****@nospam.com> wrote in message
news:vr************@corp.supernews.com...

> I'm using SendKeys:

Eric Cadwell wrote:

There is a System.Windows.Forms.SendKeys class.

HTH;
Eric Cadwell
http://www.origincontrols.com

Turns out that's the only SendKeys I'm using.

How do I find what piece(s) of the VB compatibility
DLL is (are) really being used, then?

-- frosty

[Jay B. Harlow [MVP - Outlook]]

frostalicious

Should I remove these three, as well? NO!!!!!

It sounds like you need to read about what the Imports statement does. ;-)

For details on the Imports statement and on when you may want to use it or
not use it check out:

http://msdn.microsoft.com/library/de...fVBSpec5_2.asp

Hope this helps
Jay

"frostalicious" <fr*****@nospam.com> wrote in message
news:vr************@corp.supernews.com... OK, in AssemblyInfo.vb I see the following:
Imports System.Reflection
Imports System.Runtime.CompilerServices
Imports System.Runtime.InteropServices

Recognize the third one as a DLL; don't know about
the first two. Looks like the VB compatibility is already
gone, maybe from when I removed the reference.

Should I remove these three, as well?

-- frosty

Jay B. Harlow [MVP - Outlook] wrote:

frostalicious,
I normally remove the imports looking for errors, then I remove the
reference looking for errors.

As I remove one of the above if there are a handful of errors I take
care of them as I go, if there a numerous errors I leave them and put
the item back.

Hope this helps
Jay

"frostalicious" <fr*****@nospam.com> wrote in message
news:vr************@corp.supernews.com...

> I'm using SendKeys:

Eric Cadwell wrote:

There is a System.Windows.Forms.SendKeys class.

HTH;
Eric Cadwell
http://www.origincontrols.com

Turns out that's the only SendKeys I'm using.

How do I find what piece(s) of the VB compatibility
DLL is (are) really being used, then?

-- frosty

[frostalicious]

Thanks. Not clear to me how to know what can be discarded
and what is five-bang-sign important, but I'll follow your advice
and not remove the others. The reason I thought they should
go (or, at least Interop.Scripting.dll should go) is because I can't
run the executable without placing Interop.Scripting.dll in the same
folder as my executable. I'm trying to produce one stand-alone
executable, which I can deploy without having to add any DLLs.

Your link does give details, but doesn't make it clear to me as to
when I may or may not want to us "Imports," I'm afraid. =':^<

-- frosty

Jay B. Harlow [MVP - Outlook] wrote:

frostalicious

Should I remove these three, as well? NO!!!!!

It sounds like you need to read about what the Imports statement
does. ;-)

For details on the Imports statement and on when you may want to use
it or not use it check out:

http://msdn.microsoft.com/library/de...l=/library/en-
us/vbls7/html/vblrfVBSpec5_2.asp

Hope this helps
Jay

"frostalicious" <fr*****@nospam.com> wrote in message
news:vr************@corp.supernews.com...

OK, in AssemblyInfo.vb I see the following:
Imports System.Reflection
Imports System.Runtime.CompilerServices
Imports System.Runtime.InteropServices

Recognize the third one as a DLL; don't know about
the first two. Looks like the VB compatibility is already
gone, maybe from when I removed the reference.

Should I remove these three, as well?

-- frosty

Jay B. Harlow [MVP - Outlook] wrote:

frostalicious,
I normally remove the imports looking for errors, then I remove the
reference looking for errors.

As I remove one of the above if there are a handful of errors I take
care of them as I go, if there a numerous errors I leave them and
put the item back.

Hope this helps
Jay

"frostalicious" <fr*****@nospam.com> wrote in message
news:vr************@corp.supernews.com...
>> I'm using SendKeys:

Eric Cadwell wrote:
>
> There is a System.Windows.Forms.SendKeys class.
>
> HTH;
> Eric Cadwell
> http://www.origincontrols.com

Turns out that's the only SendKeys I'm using.

How do I find what piece(s) of the VB compatibility
DLL is (are) really being used, then?

-- frosty