| Groups | Blog | Home |
visual c : How are we supposed to remote debug our mixed application?
We have a mixed application that includes managed and unmanaged code. Until
recently we've been able to remote debug by disabling the security policy to get the MFC managed dlls to load properly over the network. However, we are now using classes in the system.data.dll assembly which according to connect.microsoft.com is not allowed to run with the security policy disabled. Here is the quote from them: In the 2.0 version of .NET, you can no longer turn off CAS policy checking on assemblies with code that can't be verified. This includes System.Data.dll. Please note that the performance gain in turning off policy checking is much smaller in 2.0 than in 1.1, so if you are using caspol to increase compiler performance, that should no longer be needed. Our only option is to now copy the mfc debug dlls manually or create a script to install them and disregard the non-redistributable licence. Please help us overcome this issue.
That's fine for our lab environment but what if we want to remote debug a
problem on a field machine. We develop an embedded application that runs on dedicated hardware. Our users are all internal but it would be very painful to be forced to insall Visual Studio on over 120 target systems just so we can debug a failure. [quoted text, click to view] "Ben Voigt [C++ MVP]" wrote:
> > "BWB" <BWB@discussions.microsoft.com> wrote in message > news:E90304A7-18C1-491D-BD41-B40342025FFE@microsoft.com... > > We have a mixed application that includes managed and unmanaged code. > > Until > > recently we've been able to remote debug by disabling the security policy > > to > > get the MFC managed dlls to load properly over the network. However, we > > are > > now using classes in the system.data.dll assembly which according to > > connect.microsoft.com is not allowed to run with the security policy > > disabled. Here is the quote from them: > > > > In the 2.0 version of .NET, you can no longer turn off CAS policy checking > > on assemblies with code that can't be verified. This includes > > System.Data.dll. Please note that the performance gain in turning off > > policy > > checking is much smaller in 2.0 than in 1.1, so if you are using caspol to > > increase compiler performance, that should no longer be needed. > > > > Our only option is to now copy the mfc debug dlls manually or create a > > script to install them and disregard the non-redistributable licence. > > Please > > help us overcome this issue. > > IANAL, but I think the license doesn't present a problem. > > You cannot redistribute the debug dlls, but Visual Studio (and therefore the > debug MFC dlls) are licensed per-developer, not per-machine. So you can > install Visual Studio or any portion thereof on multiple machines, as long > as they are only used by developers who already have a license. > > > > > Brandon > >
[quoted text, click to view] "BWB" <BWB@discussions.microsoft.com> wrote in message news:E90304A7-18C1-491D-BD41-B40342025FFE@microsoft.com... > We have a mixed application that includes managed and unmanaged code. > Until > recently we've been able to remote debug by disabling the security policy > to > get the MFC managed dlls to load properly over the network. However, we > are > now using classes in the system.data.dll assembly which according to > connect.microsoft.com is not allowed to run with the security policy > disabled. Here is the quote from them: > > In the 2.0 version of .NET, you can no longer turn off CAS policy checking > on assemblies with code that can't be verified. This includes > System.Data.dll. Please note that the performance gain in turning off > policy > checking is much smaller in 2.0 than in 1.1, so if you are using caspol to > increase compiler performance, that should no longer be needed. > > Our only option is to now copy the mfc debug dlls manually or create a > script to install them and disregard the non-redistributable licence. > Please > help us overcome this issue. IANAL, but I think the license doesn't present a problem. You cannot redistribute the debug dlls, but Visual Studio (and therefore the debug MFC dlls) are licensed per-developer, not per-machine. So you can install Visual Studio or any portion thereof on multiple machines, as long as they are only used by developers who already have a license. [quoted text, click to view] > > Brandon
Ben,
Thanks for your response. I guess we could just install the dlls on the target machines. Do you have any tips on how to install them into the SxS folder? Can they just be copied there? Do they need a special manifest? Brandon [quoted text, click to view] "Ben Voigt [C++ MVP]" wrote:
> > "BWB" <BWB@discussions.microsoft.com> wrote in message > news:9BF9F8F1-ADB1-48EC-8346-C625D586F1D4@microsoft.com... > > That's fine for our lab environment but what if we want to remote debug a > > problem on a field machine. > > > > We develop an embedded application that runs on dedicated hardware. Our > > users are all internal but it would be very painful to be forced to insall > > Visual Studio on over 120 target systems just so we can debug a failure. > > If you have a license for Visual Studio, I don't see why you can't install > just the pieces you need, in this case the DLLs. > > You can also debug without the MFC debug DLLs. There are three independent > settings: > > MFC DLLs are debug or release > compiler optimizations are off or on > debug symbols are generated or not > > The default project settings use all the first alternatives for Debug and > all the second alternatives for Release, but for example generating debug > symbols for an optimized build using the release MFC DLLs is very possible. > > > > > > "Ben Voigt [C++ MVP]" wrote: > > > >> > >> "BWB" <BWB@discussions.microsoft.com> wrote in message > >> news:E90304A7-18C1-491D-BD41-B40342025FFE@microsoft.com... > >> > We have a mixed application that includes managed and unmanaged code. > >> > Until > >> > recently we've been able to remote debug by disabling the security > >> > policy > >> > to > >> > get the MFC managed dlls to load properly over the network. However, > >> > we > >> > are > >> > now using classes in the system.data.dll assembly which according to > >> > connect.microsoft.com is not allowed to run with the security policy > >> > disabled. Here is the quote from them: > >> > > >> > In the 2.0 version of .NET, you can no longer turn off CAS policy > >> > checking > >> > on assemblies with code that can't be verified. This includes > >> > System.Data.dll. Please note that the performance gain in turning off > >> > policy > >> > checking is much smaller in 2.0 than in 1.1, so if you are using caspol > >> > to > >> > increase compiler performance, that should no longer be needed. > >> > > >> > Our only option is to now copy the mfc debug dlls manually or create a > >> > script to install them and disregard the non-redistributable licence. > >> > Please > >> > help us overcome this issue. > >> > >> IANAL, but I think the license doesn't present a problem. > >> > >> You cannot redistribute the debug dlls, but Visual Studio (and therefore > >> the > >> debug MFC dlls) are licensed per-developer, not per-machine. So you can > >> install Visual Studio or any portion thereof on multiple machines, as > >> long > >> as they are only used by developers who already have a license. > >> > >> > > >> > Brandon > >> > >> > >> > >
[quoted text, click to view] "BWB" <BWB@discussions.microsoft.com> wrote in message news:9BF9F8F1-ADB1-48EC-8346-C625D586F1D4@microsoft.com... > That's fine for our lab environment but what if we want to remote debug a > problem on a field machine. > > We develop an embedded application that runs on dedicated hardware. Our > users are all internal but it would be very painful to be forced to insall > Visual Studio on over 120 target systems just so we can debug a failure. If you have a license for Visual Studio, I don't see why you can't install just the pieces you need, in this case the DLLs. You can also debug without the MFC debug DLLs. There are three independent settings: MFC DLLs are debug or release compiler optimizations are off or on debug symbols are generated or not The default project settings use all the first alternatives for Debug and all the second alternatives for Release, but for example generating debug symbols for an optimized build using the release MFC DLLs is very possible. [quoted text, click to view] > > "Ben Voigt [C++ MVP]" wrote: > >> >> "BWB" <BWB@discussions.microsoft.com> wrote in message >> news:E90304A7-18C1-491D-BD41-B40342025FFE@microsoft.com... >> > We have a mixed application that includes managed and unmanaged code. >> > Until >> > recently we've been able to remote debug by disabling the security >> > policy >> > to >> > get the MFC managed dlls to load properly over the network. However, >> > we >> > are >> > now using classes in the system.data.dll assembly which according to >> > connect.microsoft.com is not allowed to run with the security policy >> > disabled. Here is the quote from them: >> > >> > In the 2.0 version of .NET, you can no longer turn off CAS policy >> > checking >> > on assemblies with code that can't be verified. This includes >> > System.Data.dll. Please note that the performance gain in turning off >> > policy >> > checking is much smaller in 2.0 than in 1.1, so if you are using caspol >> > to >> > increase compiler performance, that should no longer be needed. >> > >> > Our only option is to now copy the mfc debug dlls manually or create a >> > script to install them and disregard the non-redistributable licence. >> > Please >> > help us overcome this issue. >> >> IANAL, but I think the license doesn't present a problem. >> >> You cannot redistribute the debug dlls, but Visual Studio (and therefore >> the >> debug MFC dlls) are licensed per-developer, not per-machine. So you can >> install Visual Studio or any portion thereof on multiple machines, as >> long >> as they are only used by developers who already have a license. >> >> > >> > Brandon >> >> >>
Don't see what you're looking for? Try a search.
|
June 2003
July 2003
August 2003
September 2003
October 2003
November 2003
December 2003
January 2004
February 2004
March 2004
April 2004
May 2004
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
| home · blog · groups | Questions? Comments? Contact the dn |