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.

Brandon

"BWB" <BWB@discussions.microsoft.comwrote in message
news:E90304A7-18C1-491D-BD41-B40342025FFE@microsoft.com...

Quote:

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.

Quote:

>
Brandon

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.

"Ben Voigt [C++ MVP]" wrote:

Quote:

>
"BWB" <BWB@discussions.microsoft.comwrote in message
news:E90304A7-18C1-491D-BD41-B40342025FFE@microsoft.com...

Quote:

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.
>

Quote:

Brandon

>
>
>

"BWB" <BWB@discussions.microsoft.comwrote in message
news:9BF9F8F1-ADB1-48EC-8346-C625D586F1D4@microsoft.com...

Quote:

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.

Quote:

>
"Ben Voigt [C++ MVP]" wrote:
>

Quote:

>>
>"BWB" <BWB@discussions.microsoft.comwrote in message
>news:E90304A7-18C1-491D-BD41-B40342025FFE@microsoft.com...

Quote:

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.
>>

Quote:

>
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

"Ben Voigt [C++ MVP]" wrote:

Quote:

>
"BWB" <BWB@discussions.microsoft.comwrote in message
news:9BF9F8F1-ADB1-48EC-8346-C625D586F1D4@microsoft.com...

Quote:

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.
>
>

Quote:

"Ben Voigt [C++ MVP]" wrote:

Quote:

>
"BWB" <BWB@discussions.microsoft.comwrote 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
>
>
>

>
>
>

How are we supposed to remote debug our mixed application?

re: How are we supposed to remote debug our mixed application?

re: How are we supposed to remote debug our mixed application?

re: How are we supposed to remote debug our mixed application?

re: How are we supposed to remote debug our mixed application?

Similar .NET Framework bytes

/bytes/development

/bytes/it

/bytes/about