Hello, we have a discovered a very major issue with what appears to be the Dock Manager while compiling under a specific version of csc..
I cannot provide all the details here, because this is part of an application with IP and no quick 'sample' has been made yet to demonstrate the problem. Basically I am hoping some light could be shed on the issue so we can determine the best course of action to move forward.
Here is the problem:
We have a DockManager on a form, that contains controls from another assembly. On some developer machines, we noticed that when the dock manager is 'activated' by clicking in the form area, the entire application freezes. On some other machines, this problem does not occur. When we copy the exe (not the assembly containing the controls) from the 'good' machine to the 'bad' one.. the freeze stops.
So far, we have narrowed down the issue to a specific version of the csc compiler:
The compiler that works:
Framework V2.0.50727
File Version: 8.0.50727.312
Product Version: 8.0.50727.312
Size: 69.0KB
Date Modified: 11/2/2006 10:34pm
The compiler that does not work:
Framework V2.0.50727
File Version: 8.0.50727.1433
Product Version: 8.0.50727.1433
Size: 78.4KB
Date Modified: 1/3/2008 3:30pm
This shows so far that the latest updates to Vistual Studio 2005 WHILE RUNNING UNDER VISTA result in an executable assembly where any user interaction with the DockManager will result in an application freeze/hang (no exception, simply a non-responding application).
Now, I have been able to reproduce the freeze by setting the Compatibility mode of the exe to Windows 2000.. executing this under vista will result in a freeze, even using the exe produced from the 'old' compiler.
And further, I have been able to prevent this freeze under W2K compatibility by setting this in the main func:
However, this makes no difference if the exe is produced by the 'new' compiler.
At this point, we are taking drastic action and removing all DockManager's from our application - this is obviously not our preferred course of action, but at this time we see no other workaround. Any help/suggestions you can provide would be much appreciated!
Regards,
Capstone Technology
I cannot provide all the details here, because this is part of an application with IP and no quick 'sample' has been made yet to demonstrate the problem. Basically I am hoping some light could be shed on the issue so we can determine the best course of action to move forward.
Here is the problem:
We have a DockManager on a form, that contains controls from another assembly. On some developer machines, we noticed that when the dock manager is 'activated' by clicking in the form area, the entire application freezes. On some other machines, this problem does not occur. When we copy the exe (not the assembly containing the controls) from the 'good' machine to the 'bad' one.. the freeze stops.
So far, we have narrowed down the issue to a specific version of the csc compiler:
The compiler that works:
Framework V2.0.50727
File Version: 8.0.50727.312
Product Version: 8.0.50727.312
Size: 69.0KB
Date Modified: 11/2/2006 10:34pm
The compiler that does not work:
Framework V2.0.50727
File Version: 8.0.50727.1433
Product Version: 8.0.50727.1433
Size: 78.4KB
Date Modified: 1/3/2008 3:30pm
This shows so far that the latest updates to Vistual Studio 2005 WHILE RUNNING UNDER VISTA result in an executable assembly where any user interaction with the DockManager will result in an application freeze/hang (no exception, simply a non-responding application).
Now, I have been able to reproduce the freeze by setting the Compatibility mode of the exe to Windows 2000.. executing this under vista will result in a freeze, even using the exe produced from the 'old' compiler.
And further, I have been able to prevent this freeze under W2K compatibility by setting this in the main func:
Application.SetCompatibleTextRenderingDefault(true);
However, this makes no difference if the exe is produced by the 'new' compiler.
At this point, we are taking drastic action and removing all DockManager's from our application - this is obviously not our preferred course of action, but at this time we see no other workaround. Any help/suggestions you can provide would be much appreciated!
Regards,
Capstone Technology