June 2005 - Posts
You know, there are some great new WinForms controls in .NET 2.0. It's
obvious that Microsoft has spent a lot of time making WinForms better than it
was in 1.X. But having spent the last several days building WinForms 2.0 demos,
I'm extremely frustrated at the holes that are still all over the place. Maybe
I'm just dumb and don't know what I'm doing, or maybe I really do need a college
degree to do this stuff, but some things that are supposed to be intuitive are
anything but. Just a few of my frustrations (please jump in if you know the
answers to any of these):
- MenuStrips and ToolStrips are cool, but for the life of me, I can't figure
out how to assign an ImageList to a ToolStrip to be able to set the ImageIndex
property
- You can't DataBind to a TreeView or ListView control
- You can't get a TreeNode by name or text
- You can't use an XML file as a DataSource without infering a schema and
converting that to a DataSet
- You can't create a new SplitterPanel in memory and substitute it for
another at runtime with the SplitContainer control
- You can't layout several bits of information in a ListView control (to
have an Outlook-like mail items UI) without some serious OwnerDraw
overriding
WinForms 2.0 is still severely lacking on discoverability. Why is it that the
same controls in WebForms are far more advanced than the ones in WinForms? I
mean, come on... I can't databind an XML file to a TreeView? Am I the first one
to ever try that scenario? I highly doubt it. I shouldn't have to get an
Infragistics control to DataBind a frickin TreeView. Seriously.
Don't get me wrong, many of the other changes are awesome. I know you guys
have worked hard. But I thought I was building a "rich experience" on the
desktop. I can't do that when the web version has more of the basics nailed than
the Windows version does.
If WinForms development at Microsoft is being forsaken to flesh out Avalon,
I'm gonna be severely pissed if some of these basics are missing when Orcas
comes out.
Bottom Line: The built-in WebForms controls are head and shoulders
above their WinForms brethren.
</rant>
Alright, it's official. As of today I'm no longer an ASP.NET MVP. My focus in
software development has been shifting towards thick and smart client
development for a while now, and I've been liking it a lot. Since the focus on
LonghornBlogs.com is primarily on the Windows client, it's fitting that I'm now
a Windows Client MVP instead. I'll still have a lot to contribute on the web
development side, but I'm much happier with how everything fits together
now.
I'm looking forward to meeting the other Windows Client MVPs in September,
and hopefully getting some more dirt on Longhorn.
I'm in San Diego this weekend, so I'll catch you all again on
Wednesday.
I've had a number of people give me great feedback on the MSBuild
Toolkit I put out last week, and I wanted to note all the issues that
I'm currently investigating.
VS.NET hangs when accessing the "Build | MSBuild
Configuration " option from the MenuBar.
Description:
When attempting to access the add-in dialog
for the first time, if you use the option from the "Build" menu instead of the
project's right-click menu, Visual Studio 2005 will hang as if a modal dialog is
open but not visible.
Symptoms:
- You cannot bring Visual Studio 2005 into
focus.
- You can only close Visual Studio 2005 from the Task Manager.
-
The VS2005 icon disappears from the "Alt-Tab" menu in Windows.
Cause:
Unknown at this time.
Workaround:
Always access the "MSBuild Configuration"
menu option from the project's right-click menu the first time you use it in an
open application. You can access it from the "Build" menu after you've opened it
from the project's menu.
Status:
Under investigation, fix scheduled for RC2
The Add-in "MSBuild Commander" fails to load with error
number 80070002
Description:
The add-in fails to load when VS2005 starts
up.
Symptoms:
After installing the MSBuild Toolkit, you
encounter the following message when starting VS2005:
"The add-in 'MSBuild
Commander' failed to load or caused an exception. Would you like to remove this
Add-in? If you choose yes, the file it was loaded from,
'*path*\MSBuildCommander.AddIn', will be renamed.
Error message: The system
cannot find the file specified.
Error number: 80070002"
Cause:
VS2005's new add-in model makes you use an XML
file for your add-in registration. In order to specify the add-in assembly
location, you must either specify a full path, or install the assembly into the
GAC. To fix this, I either have to create a post-install action that modifies
the XML file with the full path, or install the assemblies to the GAC. Using the
GAC is pre-release software is generally not advisable, because it can introduce
un-installation hassles.
Workaround:
You MUST install the Toolkit in the default
installation folder.
Status:
Resolved for RTM
The WinForms Designer Fails When Designing a Form Targeted
to an Older Version of .NET
Description:
When creating a new WinForms project in
Visual Studio 2005 (NOT upgrading from VS.NET 2003), if you select an older
version of .NET to compile to, the WinForms designer will fail to load the form
for design-time interaction.
Symptoms:
The WinForms Designer shows an error message
when opening a form in Design View.
Cause:
.NET 2.0 has a new feature called
Partial Types that allow you to break out a class into multiple files.
VS2005 uses this feature to separate the designer-generated code from the form's
procedural code. Apparently, Visual Studio 2005 uses the version specified in
the MSBuild target to load up the form in the designer. Since older versions of
.NET do not support partial types, the design-time experience will be
broken.
Workarounds:
There are two options -
- Upgrade your existing VS.NET 2003 WinForms application to VS2005. During
the upgrade process, the designer will not separate out existing forms into
partial classes.
- If you create a new WinForms project with VS2005, and you must compile a
native 1.1 assembly, you need to combine all the partial class files into a
single class before attempting to design any forms of compile the
application.
I am currently investigating the possibility of an addition to the add-in
that will perform a one-time conversion of partial types into single class
files.
Status:
By Design. Documentation fixed for RC2.
New Projects Created in VS2005 Fail to Compile to Older
Versions of .NET
Description:
Projects that are created from scratch and
not upgraded from VS.NET 2003 will not compile to .NET 1.1 or 1.0 after the
configuration is changed.
Symptoms:
No assemblies are emitted by the compiler.
Cause:
There are a bunch of new namespaces and types that
are not supported by older versions of .NET. There are several default options
in VS2005 (for example, globally importing the
"System.Collections.Generic") that are not backwards compatible.
Workaround:
- Double-click the "My Project" item in the Solution Explorer. Select the
"References" tab, and uncheck any 2.0-specific imported namespaces.
- Surround any non-.NET 2.0 code in conditional compilation constants. For
example: "#IF NOT NET11 OR NET10"
- Recompile. It may take several attempts at compiling to clear up all the
compilation issues.
Status:
By Design. Documentation fixed for RC2.
VS2005 Projects Containing COM References Fail to
Compile to Older Versions of .NET
Description:
Projects created in or upgraded to VS2005
that utilize COM Interop will not compile to .NET 1.1 or 1.0
Symptoms:
No assemblies are emitted by the compiler.
Cause:
The Runtime-Callable Wrapper generated by Visual
Studio 2005 references MSCoreLib.dll Version 2.0.50515. The
backwards-compatibility targets do not change the references for the RCW.
Workaround:
None at this time.
Status:
Under Investigation.
That's about it for now. I'll post more as the feedback comes in. I'm headed to
Colorado this weekend to attend the wedding of a stepsister I've never met, so I
probably won't be able to post any updates until next week at the
earliest.
Now that I've finally released a
backwards-compatibility toolkit for MSBuild that I'm happy with, I'm taking
a huge leap. I'm uninstalling Visual Studio .NET 2003 from my machine. I'm gonna
see if it really is possible to do 100% of my .NET 1.1 work from Visual Studio
2005. Heh, the only way to find out is to try, right?
<crosses fingers> Here goes nothing...
This download has been removed. A new one will be posted in April 2006.
The MSBuild Toolkit for Visual Studio 2005 RC is the long-awaited successor to the MSBuild Compatibility Toolkit that I released late last year. Thanks to the work of Jomo Fisher, Mark Michaelis, and others, I've been able to put together a toolset that delivers on what I wanted to do since I first saw MSBuild at the Whidbey Alpha Design Review two years ago.
What Is It?
The MSBuild Toolkit for Visual Studio 2005 RC consists of two distinct parts:
- Drastically improved .TARGETS files for compiling MSBuild-based projects to .NET 1.1 and 1.0.
- A Visual Studio 2005 add-in that helps you manage the .TARGETS files your projects are referencing.
Lets take a look at these parts in depth.
Improved .TARGETS Files
After I released the first toolkit (based on the work of Jomo Fisher), Mark Michaelis and others led the charge to improve support for other runtimes through the underlying build engine. When .NET 2.0 Beta 2 was released, Jomo released the result of that work in a sample .TARGETS file that allowed C# projects to compile to .NET 1.1. This version allowed you to add other frameworks as options in the "Build Configuration" dialog. This is really powerful, as it allows you to compile to different frameworks individually, and batch build to all supported versions later on.
These new targets are significantly smaller than their predecessors, and far less brittle. They now handle non-Framework assembly references really well, and the whole system is practically seamless. It's really slick, and Jomo did a great job of laying the foundation for this project.
Besides support for Visual Basic and .NET 1.0 (which I added, and is included in this release), I still felt that a crucial portion of UI was missing...
Configuring Project Targets
Even with all this functionality, Visual Studio was still missing a way to manipulate the Project file (to change it's tags) without leaving the IDE. So I wrote an add-in that takes care of that for you. It gives you a UI similar to your project assembly references, and lets you select from the available targets installed on the system. You can see that UI below.
![]()
Figure 1: Managing Imported Targets
You can access this functionality from either of the following menu commands:
![]()
![]()
Figure 2: Assessing the Configuration Dialog
Why Did I Put This Together?
Visual Studio 2005 is an extremely compelling development environment. After using it so much in the Alpha and Beta 1, the thought of developing new Community Server add-ons in VS.NET 2003 was really disheartening. This package has allowed me to develop a ton of new code for LonghornBlogs.com using the Class Designer, Code Snippets, and Refactoring, while compiling for .NET 1.1 (because CS 1.0 was not compatible with ASP.NET 2.0).
Also, while Interscape has stopped building ASP.NET components for now, we might re-enter the market in the near future. One of the most time-consuming parts of the development cycle was maintaining two project files in two different IDEs that share the same source code files. This problem was one of the driving forces in giving our component business a break, and now supporting older versions of the Framework is much more feasible.
What's Still Missing?
While the add-in works, I'm not really happy with it at all. The whole process for building an add-in is TERRIBLE (Note to the VS Core Team: HIRE JAMIE CANSDALE!!!) and not for the faint of heart. I haven't been able to figure out how to remove commands on uninstall, so for now that part will be buggy.
Ultimately, I'd like the form for the add-in to either a) appear as a tab on the Project Properties form, or b) dock in the Document pane like the Project Properties form. I've forwarded the code for the Toolkit to the MSBuild team and the Group Product Manager for VS Core, so hopefully this kit will find it's way into VS2005, either as a "VB Refactor"-type addon, or a part of the code product. Whether or not you compile to older versions of the Framework, I think the ability to configure your Project Targets is extremely important, and maybe this will kickstart the team into making it into VS2005 RTM.
The TARGETS files, on the other hand, I'm pretty satisfied with. They work in all my scenarios. Hopefully they'll work in yours too.
Getting Support
I want to make this Toolkit better. So if you have any issues, list them here in my commants or e-mail me thru my contact page, and I'll get them fixed ASAP.
Downloading the Release Candidate
Download version 2.0.50602 here.
Thanks to everyone who made this possible. Hope it is of use you guys.
More Posts