all groups > vb.net upgrade > november 2003 >
You're in the vb.net upgrade group:
.exe throws exception from local, but not network drive
vb.net upgrade:
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
[quoted text, click to view] > "frostalicious" <frostyj@nospam.com> wrote in message > news:vr3lksl8cpbj93@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
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 [quoted text, click to view] 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" <frostyj@nospam.com> wrote in message > news:vr4k6fqg9ffi8c@corp.supernews.com... >>> "frostalicious" <frostyj@nospam.com> wrote in message >>> news:vr3lksl8cpbj93@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
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 ------------------------------ [quoted text, click to view] "frostalicious" <frostyj@nospam.com> wrote in message news:vr3lksl8cpbj93@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, [quoted text, click to view] > 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 [quoted text, click to view] "frostalicious" <frostyj@nospam.com> wrote in message news:vr4k6fqg9ffi8c@corp.supernews.com... > > "frostalicious" <frostyj@nospam.com> wrote in message > > news:vr3lksl8cpbj93@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 > >
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] ---- [quoted text, click to view] "frostalicious" <frostyj@nospam.com> wrote in message news:vr4om7o64al0e8@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" <frostyj@nospam.com> wrote in message > > news:vr4k6fqg9ffi8c@corp.supernews.com... > >>> "frostalicious" <frostyj@nospam.com> wrote in message > >>> news:vr3lksl8cpbj93@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 > >
I'm using SendKeys: Assembly Microsoft.VisualBasic.Compatibility C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\Microsoft.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 [quoted text, click to view] 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] [quoted text, click to view] >>> [It] was another >>>> missing DLL, namely Microsoft.VisualBasic.Compatibility.dll and >>>> when I copied that DLL to the server, my app started to work.
If this is the only method you're using from the Compatibility library then you can easily just use either of the framework SendKey methods. System.Windows.Forms.SendKeys.SendWait(Keys) System.Windows.Forms.SendKeys.Send(Keys) The only difference between the two is if the system waits for the send key messages to be processed or not. See http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/ frlrfsystemwindowsformssendkeysclasssendwaittopic.asp for more information. The Upgrade Wizard only upgrades to the Compatibility library version because it's not able to determine the value of Wait at the time of Upgrade. I expect however that your upgraded code may in fact use other methods from the Compatibility library so this may not entirely eliminate your need to deploy it along with your project. -- John Hart, Microsoft VB Team This posting is provided "AS IS" with no warranties, and confers no rights. -------------------- [quoted text, click to view] > From: "frostalicious" <frostyj@nospam.com> > Newsgroups:
microsoft.public.dotnet.framework,microsoft.public.dotnet.framework.setup,mi crosoft.public.dotnet.languages.vb,microsoft.public.dotnet.languages.vb.upgr ade [quoted text, click to view] > Subject: Re: Microsoft.VisualBasic.Compatibility.dll (was: .exe throws exception from local, but not network drive) > Date: Wed, 12 Nov 2003 11:39:30 -0800 > Organization: Posted via Supernews, http://www.supernews.com > Message-ID: <vr533j7f37jn3f@corp.supernews.com> > Reply-To: "frostalicious" <frostyj@nospam.com> > References: <vr3lksl8cpbj93@corp.supernews.com> <#yMYsmOqDHA.2000@TK2MSFTNGP12.phx.gbl> <vr4k6fqg9ffi8c@corp.supernews.com> <Ol4$uKTqDHA.2584@TK2MSFTNGP09.phx.gbl> <vr4om7o64al0e8@corp.supernews.com> <uJ19H9UqDHA.372@TK2MSFTNGP11.phx.gbl> [quoted text, click to view] > X-Priority: 3 > X-MSMail-Priority: Normal > X-Newsreader: Microsoft Outlook Express 6.00.2800.1158 > X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 > X-Complaints-To: abuse@supernews.com > Lines: 62 > Path:
cpmsftngxa06.phx.gbl!TK2MSFTNGP08.phx.gbl!newsfeed00.sul.t-online.de!t-onlin e.de!newsfeed.icl.net!newsfeed.fjserv.net!news.tele.dk!news.tele.dk!small.ne ws.tele.dk!sn-xit-02!sn-xit-04!sn-xit-01!sn-post-02!sn-post-01!supernews.com !corp.supernews.com!not-for-mail [quoted text, click to view] > Xref: cpmsftngxa06.phx.gbl microsoft.public.dotnet.framework.setup:6389
microsoft.public.dotnet.languages.vb:156233 microsoft.public.dotnet.languages.vb.upgrade:5852 microsoft.public.dotnet.framework:58719 [quoted text, click to view] > X-Tomcat-NG: microsoft.public.dotnet.languages.vb.upgrade > > I'm using SendKeys: > > Assembly Microsoft.VisualBasic.Compatibility > C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\Microsoft.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. > > >
Don't see what you're looking for? Try a search.
|
|
|