Something strange has happened on my machine.
I tried using n UltraListView this afternoon for the first time ever and was surprised to see it land in the Form's Component Tray. I'd read up on the object and was sure it is a control, not a component.
After trying the same thing in a brand new, clean Windows Forms project, I gave up when the same thing behaviour repeated every time. I decided that there was soemthing odd about that type of object and went on to some other work.
Later on, when I dragged an UltraGrid onto my form and saw it land in the Component Tray, I realized that something could be generally amiss.
I've since played with a dozen other controls and half of them are acting as components.
At some point after the first UltraViewList acted odd, I used Document Outline to try and move the object into a different container on my form; into an ExpandableGroupBox. This caused VS to crash. Of course, I tried that a second time after restarting VS and met with the same fate.
This morning, I installed the latest hotfix (NetAdvantage_20083_CLR2X_WIN_HotFix_2039). Tomorrow, we're going to see if the same behaviour is occurring on another dev machine.
In the meantime, here is a list of the controls that I've tried, grouped into those that function correctly, and those that don't.
Does anybody see a pattern that might suggest a simple fix?
Thanks.
Those that behave properly:...Misc.UltraButton...Misc.UltraExpandableGroupBox...Misc.UltraLabel...UltraWinEditors.UltraDateTimeEditor...UltraWinEditors.UltraWinCalc.UltraCalculator...UltraWinSchedule.UltraDayView...UltraWinSchedule.UltraMonthViewSingle...UltraWinStatusBar.UltraStatusBar
Those that end up in Component Tray:...FormattedLinkLabel.UltraFormattedLinkLabel...FormattedLinkLabel.UltraFormattedTextEditor...UltraWinGauge.UltraGauge...UltraWinGrid.UltraDropDown...UltraWinGrid.UltraGrid...UltraWinListView.UltraListView...UltraWinTree.UltraTree
Updating the licenses.licx file is just as vaild of a solution as emptying out the NetAdvantage references from the file. If you empty out the file, then Visual Studio will re-add referneces (based on the version of the assemblies your project has as references) when it decides that it needs it; that's why the Project Upgrade Utility simply removes the references. Updating the file manually is a little bit more work, and gives you the security of knowing how the file was updated and when.
I had to perform one last step to make this work.
The licenses.lix files in the project had the old version of the dll in them; I did a search/replace on that number and replaced it with .2039 to match the hotfix.
I tried running the Upgrade Tool but noticed that all it did was empty out the licenses files.
john_m said:1) Should we always do this?
Using the Project Upgrade Utility (or Project Upgrade Add-In) on your projects after applying a hot fix should correct the version each reference uses, without the need to set the Specific Version property on the references. It's an extra step each time you apply a hot fix.
john_m said:2) Do we run any risk by doing this?
I've never personally seen anything go wrong by setting this to false, nor have I seen any support reports of such issues. In fact, I see a lot of posts on MSDN forums suggesting setting it to false. This leads me to believe that there is little or no risk.
john_m said:3) Is there any way to configure the Infra environment to apply the UseSpecificVersion property as False by default?
Vince,
1) Should we always do this?
2) Do we run any risk by doing this?
3) Is there any way to configure the Infra environment to apply the UseSpecificVersion property as False by default?
Thanks Emanuel ! That did it.