June 09, 2008 | Comments: (0)
Over on the Advice Line blog, a reader who signs himself "Need help from Bill Gates" asked Bob Lewis about an upgrade project from a Windows application using MDI to the .Net Framework. The architects he talked to pooh-poohed Windows Forms as "old school" and pushed Web applications, Windows Presentation Framework, and Silverlight. Bob said "it depends" and suggested another conversation with the architects about fashion vs. style.
Here's my answer:
Dear Need-Bill ...
You need to talk to different architects, ones who will listen to what you want and analyze what you need instead of pushing the latest technology because it's glitzy.
Web applications have an advantage over desktop applications when it comes to installation and accessibility, but they aren't as responsive as desktop applications at this point. Windows Forms (WinForms) is the right technology if you want to build a Windows desktop application with the .Net Framework that will provide maximum productivity to people who use the application heavily, especially if they enter lots of data.
Windows Presentation Framework (WPF) offers additional graphical capabilities for desktop applications, but requires more in the way of hardware than WinForms to run well. I'm not sure your customers need or could benefit from the advanced graphics, and they might not want to upgrade their computers to run it.
Silverlight is a rich Internet application technology. It implements a subset of WPF as a Web browser plug-in.
Beautiful things can be done with Silverlight rich Internet applications, but you'd need Silverlight 2.0 if you wanted to build one that would be useful for line-of-business or data entry: Silverlight 1.0 doesn't even have a native text input control. Silverlight 2.0 has not yet been released: it is still being beta tested, and beta 2 was just released on Friday.
Posted by Martin Heller on June 9, 2008 08:03 AM
May 13, 2008 | Comments: (0)
Visual Studio 2008 SP1: To beta, or not to beta?
As I mentioned in An old Visual Studio problem rears its ugly head back in February, I've been looking forward to SP1 for Visual Studio 2008 and NET Framework 3.5. Why? These are supposed to fix most of the problems I've been having with Visual Studio, and restore most of the functionality that was cut from the initial 2008 release.
SP1 is out, but only as a first beta-test version. As is true with most beta-test products, there are risks to running it, ranging from a high likelihood of encountering new bugs to a low likelihood of trashing your system to the point where your most effective option is to reinstall Windows from scratch on a newly formatted partition, also known by the woodworking analogy of scraping your drive down to the bare bits.
The list of improvements in this version is impressive. Both Scott Guthrie and Brad Abrams have discussed these in their blogs. Brad does a great job of covering new features; Scott does too, in a slightly different way, and also highlights the known incompatibilities.
Here are the "gotchas", copied from Scott's blog:
1) If you are running Windows Vista you should make sure you have Vista SP1 installed before trying to install .NET 3.5 SP1 Beta. There are some setup issues with .NET 3.5 SP1 when running on the Vista RTM release. These issues will be fixed for the final .NET 3.5 SP1 release - until then please make sure to have Vista SP1 installed before trying to install .NET 3.5 SP1 beta.
2) If you have installed the VS 2008 Tools for Silverlight 2 Beta1 package on your machine, you must uninstall it - as well as uninstall the KB949325 update for VS 2008 - before installing VS 2008 SP1 Beta (otherwise you will get a setup failure). You can find more details on the exact steps to follow here (note: you must uninstall two separate things). It is fine to have the Silverlight 2 runtime on your machine with .NET 3.5 SP1 - the component that needs to be uninstalled is the VS 2008 Tools for Silverlight 2 package. We will release an updated VS 2008 Tools for Silverlight package in a few weeks that works with the VS 2008 SP1 beta.
3) There is a change in behavior in the .NET 3.5 SP1 beta that causes a problem with the shipping versions of Expression Blend. This behavior change is being reverted for the final .NET 3.5 SP1 release, at which time all versions of Blend will have no problems running. Until then, you need to download this recently updated version of Blend 2.5 to work around this issue.
I wouldn't install this version on my primary development system, but I might install it on a secondary development system after doing a full back-up.
To beta, or not to beta? Maybe both.
Posted by Martin Heller on May 13, 2008 11:37 AM
October 18, 2007 | Comments: (0)
Creating and Using a Data Access Layer with Visual Studio 2005
Every time I do this I have to figure it out again. (Sometimes I empathize with HAL, when he is being dismantled at the end of 2001: "My mind is going, Dave. I can feel it.") I'm blogging this as much for myself as for anyone else it might help.
Here is the magic spell you need:
- Create a Class Library project in your solution in the supported language of your choice. I like C#, but Visual Basic .NET also works. I usually end the project name with DAL so that I can remember what it is.
- Delete the Class1.cs (or .vb) source file that is created automatically.
- Right-click on the project and add a new DataSet item. The design surface for an XSD file will open.
- Open a data connection to the database you're wrapping.
- Select each table you want to use and drag it to the design surface.
- Build the data access layer project.
- Add a reference to the data access layer project to your UI project. It doesn't really matter whether the UI project is a Windows Forms application, an ASP.NET application, a console application, or a Windows Presentation Foundation application.
- Add a using (or Imports) statement for the table adapters of the data access layer to your UI project. IntelliSense will help out if you added the reference properly.
Now you can instantiate the table adapters in your code and call the appropriate pre-generated methods for whatever CRUD operations you need. If you need other operations, you can go back to the DAL and add them: right click at the bottom of the table in the DataSet diagram and add a query.
Posted by Martin Heller on October 18, 2007 08:06 AM
October 09, 2007 | Comments: (0)
Developers, Designers, and WPF
As I mentioned yesterday, I heard at ReMIX from two teams of developers and designers who had completed WPF (Windows Presentation Foundation) projects using the Microsoft Visual Studio developer tools and Expression designer tools. The good news is that it can be made to work better than it used to, since Visual Studio and Expression integrate with common XAML; the bad news is that it still isn't completely smooth.
How do you make it work? First, everybody has to be working from the same design documents and use cases and in general have some common understanding of what it is you're trying to accomplish. I know, that sounds like Motherhood and Apple Pie, but all too often it's a major stumbling block.
Second, you need a centralized repository that everyone can access. That can be a problem for designers, who often aren't familiar with the need to check artifacts in and out. It can also be a problem for the tools: for example, the September Preview of Expression Blend 2 still isn't able to check files in and out of Microsoft TFS (Team Foundation Server). In addition, TFS doesn't do a very good job of merging XML documents, and XAML is just a dialect of XML. (You don't have to use TFS, of course, but both of these groups did.)
Third, while developers can work entirely in Visual Studio, designers cannot work entirely in Expression Studio: they also need to use Visual Studio, at least a few times a day. Unfortunately, Visual Studio tends to put designers off: they have a hard time getting used to the whole idea of projects, much less getting the idea of needing to rebuild projects after the developers have changed some infrastructure that doesn't seem like it should matter, or the idea of refreshing projects from the repository.
Fourth, both developers and designers need to understand what they can and can't change about each other's XAML. Developers have to learn to stay away from blocks of XAML that reflect carefully tuned designs; designers have to learn not to touch the names of XAML objects, since the names are what tie the XAML to the scripting. It turns out that it's often OK to change the types of objects: as long as the original object type (a StackFrame, perhaps) and the new object type (a Canvas, perhaps) share all the events and methods being used by the application, you're golden.
Both the Magenic CV application and the Infragistics Tangerine application show that you can build creative applications with WPF, of the sort that previously might have been built in Adobe Flash or Flex. This of course will trigger my distinguished colleague Tom Yager, who thinks that nobody in his or her right mind would give up Flash.
What I heard from these people, however, was that there are difficult cultural problems that often can't be overcome in a Microsoft development shop that also employs designers who use Flash. They can be overcome with these tools: designers can learn Expression since it's so much like the Adobe tools they know, and then they can become an integral part of the development cycle instead of a forethought or an afterthought.
Tony Handley described the alternatives quite graphically. If the designers come in at the beginning and give their concepts to the developers as drawings, the developers throw up their hands, say it can't be done, and do whatever they can, and the result comes out looking nothing like the original concept. If the designers come in at the end to gussy up a working application, they basically have the job of putting lipstick on a pig. With the cooperative process that is possible with WPF and XAML, they can, with some care, iterate back and forth in a way that isn't too frustrating for either the designers or the developers, and wind up with a working product that also satisfies visually.
Posted by Martin Heller on October 9, 2007 02:49 PM
May 01, 2007 | Comments: (0)
At Microsoft's MIX07 conference, the keynote was mostly about Silverlight. What is Silverlight, and why should we care about it?
Officially, Silverlight "is a cross-browser, cross-platform plug-in for delivering the next generation of .NET based media experiences and rich interactive applications for the Web." In other words, it's a browser plug-in that enables a subset of the capabilities of the Windows Presentation Foundation over the Web. It was previously called WPF/E.
From the user's viewpoint, to enable Silverlight, you download and install a 1.4 MB plugin, and then you can view Silverlight content in IE, Firefox or Safari. From a developer's viewpoint, once you have the tools installed, you instantiate Silverlight by including some JavaScript helper files from your HTML, and then you can display and script XAML files in your Web pages.
Microsoft cites four key benefits of Silverlight:
1. Compelling cross-platform user experiences
2. Flexible Programming Model with Collaboration Tools
3. High-quality media, low-cost delivery
4. Connected to data, servers, and services
Two versions of Silverlight were announced Monday: the V1.0 beta, and the V1.1 Alpha. What's the difference? The diagram below summarizes what's in each release:
.png)
Again, why should we care? If you're a cynic, Silverlight just looks like Microsoft's answer to Flash. But if you like the idea of XAML-based display, or the idea of programming in managed code, then Silverlight offers a compelling model for programming the Web client.
Posted by Martin Heller on May 1, 2007 12:38 PM
TOP STORIES
ADDITIONAL RESOURCES
- Remote Access: Maintain Security and Decrease the Burden on IT
- Beyond AntiVirus: Symantec Endpoint Protection
- What Every Enterprise Needs to Know About VDI
- Monitor the core and troubleshoot the access layer
- Solution for Open Virtualization Provides Server Consolidation
- Help Simplify Virtualization
