R
Robert Randall
Please help MSFT experts!! Visio11 is great but .NET has us scratching our
heads.
I'm using the new OCX drawing control that is part of the Visio11 technical
beta package. It is a very flexible and powerful piece. BTW, Thanks!
I've run into a .NET CLR problem that I can't seem to resolve. This only
occurs on Server 2003. It works fine on XP. I'm developing native C++ code
so I have a complete software stack to admire when problems do occur. When
executing on XP, the Visio11 pieces (and the dependent Office11 peices) do
not pull in any of the CLR and I don't experience this issue. On Win2k3,
the stack looks like
'mmc.exe': Loaded 'E:\bobert\wsMmcResultView\Debug\wsMmcResultView.dll',
Symbols loaded.
'mmc.exe': Loaded 'E:\Program Files\Microsoft Office\Visio11\VISOCX.DLL', No
symbols loaded.
'mmc.exe': Loaded 'E:\Program Files\Microsoft Office\Visio11\OMFCU.DLL', No
symbols loaded.
'mmc.exe': Loaded 'E:\Program Files\Microsoft Office\Visio11\VISLIB.DLL', No
symbols loaded.
'mmc.exe': Loaded 'C:\Program Files\Common Files\Microsoft
Shared\OFFICE11\MSO.DLL', No symbols loaded.
'mmc.exe': Loaded 'E:\Program Files\Microsoft
Office\Visio11\1033\VISINTL.DLL', No symbols loaded.
'mmc.exe': Loaded 'E:\Program Files\Microsoft
Office\Visio11\1033\OMFCSAT.DLL', No symbols loaded.
'mmc.exe': Loaded 'E:\Program Files\Microsoft Office\Visio11\MSOUTLS.DLL',
No symbols loaded.
'mmc.exe': Loaded 'C:\WINDOWS\system32\shfolder.dll', No symbols loaded.
'mmc.exe': Loaded 'C:\Program Files\Common Files\Microsoft
Shared\INK\SKCHUI.DLL', No symbols loaded.
'mmc.exe': Loaded
'C:\WINDOWS\WinSxS\x86_Microsoft.Windows.GdiPlus_6595b64144ccf1df_1.0.100.0_
x-ww_0D1F9F94\GdiPlus.dll', No symbols loaded.
'mmc.exe': Unloaded 'E:\Program Files\Microsoft
Office\Visio11\1033\VISINTL.DLL'
The thread 'Win32 Thread' (0xcc4) has exited with code 3 (0x3).
The above reference to the WinSxS directory tells me that we're pulling in
the .NET CLR which in turn will enforce the software stack security that
comes with it. I get a
The operating system is not presently configured to run this application
message box and the create for the control fails. Well, after checking all
of the documentation and the configuration of the framework I can't explain
why this would occur. The library is being loaded from the local machine
under the current user and as such should have priviledge by default.
Again, executing the same code on WinXP does NOT pull in the GdiPlus package
out of the CLR so the CLR is never loaded into the process and everything
works fine (legacy mode though it is).
This is a little complicated because it is all happening through MMC. I'm
working on an MMC snap-in.
I'm able to successfully instantiate the DrawingControl using a web page
<object> reference on the local machine without difficulty. I've attempted
a number of security changes for .NET in an attempt to resolve the problem.
However, I don't believe there should be a problem in the first place. Is
there something special about MMC that begins a special security level? I
don't believe so based on the libraries being loaded according to the
debugger. The only .NET CLR piece appears to be coupled to the
office11/visio11 control being loaded and not directly to MMC. I've tried
creating an application specific configuration for the MMC executable and
that didn't help either (I put every assembly related to the office11 piece
but could not find an assembly that was for GdiPlus).
Please advise, any help would be appreciated.
Regards,
Robert.
heads.
I'm using the new OCX drawing control that is part of the Visio11 technical
beta package. It is a very flexible and powerful piece. BTW, Thanks!
I've run into a .NET CLR problem that I can't seem to resolve. This only
occurs on Server 2003. It works fine on XP. I'm developing native C++ code
so I have a complete software stack to admire when problems do occur. When
executing on XP, the Visio11 pieces (and the dependent Office11 peices) do
not pull in any of the CLR and I don't experience this issue. On Win2k3,
the stack looks like
'mmc.exe': Loaded 'E:\bobert\wsMmcResultView\Debug\wsMmcResultView.dll',
Symbols loaded.
'mmc.exe': Loaded 'E:\Program Files\Microsoft Office\Visio11\VISOCX.DLL', No
symbols loaded.
'mmc.exe': Loaded 'E:\Program Files\Microsoft Office\Visio11\OMFCU.DLL', No
symbols loaded.
'mmc.exe': Loaded 'E:\Program Files\Microsoft Office\Visio11\VISLIB.DLL', No
symbols loaded.
'mmc.exe': Loaded 'C:\Program Files\Common Files\Microsoft
Shared\OFFICE11\MSO.DLL', No symbols loaded.
'mmc.exe': Loaded 'E:\Program Files\Microsoft
Office\Visio11\1033\VISINTL.DLL', No symbols loaded.
'mmc.exe': Loaded 'E:\Program Files\Microsoft
Office\Visio11\1033\OMFCSAT.DLL', No symbols loaded.
'mmc.exe': Loaded 'E:\Program Files\Microsoft Office\Visio11\MSOUTLS.DLL',
No symbols loaded.
'mmc.exe': Loaded 'C:\WINDOWS\system32\shfolder.dll', No symbols loaded.
'mmc.exe': Loaded 'C:\Program Files\Common Files\Microsoft
Shared\INK\SKCHUI.DLL', No symbols loaded.
'mmc.exe': Loaded
'C:\WINDOWS\WinSxS\x86_Microsoft.Windows.GdiPlus_6595b64144ccf1df_1.0.100.0_
x-ww_0D1F9F94\GdiPlus.dll', No symbols loaded.
'mmc.exe': Unloaded 'E:\Program Files\Microsoft
Office\Visio11\1033\VISINTL.DLL'
The thread 'Win32 Thread' (0xcc4) has exited with code 3 (0x3).
The above reference to the WinSxS directory tells me that we're pulling in
the .NET CLR which in turn will enforce the software stack security that
comes with it. I get a
The operating system is not presently configured to run this application
message box and the create for the control fails. Well, after checking all
of the documentation and the configuration of the framework I can't explain
why this would occur. The library is being loaded from the local machine
under the current user and as such should have priviledge by default.
Again, executing the same code on WinXP does NOT pull in the GdiPlus package
out of the CLR so the CLR is never loaded into the process and everything
works fine (legacy mode though it is).
This is a little complicated because it is all happening through MMC. I'm
working on an MMC snap-in.
I'm able to successfully instantiate the DrawingControl using a web page
<object> reference on the local machine without difficulty. I've attempted
a number of security changes for .NET in an attempt to resolve the problem.
However, I don't believe there should be a problem in the first place. Is
there something special about MMC that begins a special security level? I
don't believe so based on the libraries being loaded according to the
debugger. The only .NET CLR piece appears to be coupled to the
office11/visio11 control being loaded and not directly to MMC. I've tried
creating an application specific configuration for the MMC executable and
that didn't help either (I put every assembly related to the office11 piece
but could not find an assembly that was for GdiPlus).
Please advise, any help would be appreciated.
Regards,
Robert.