Tagged with ASP.NET
Today I was renewed as an MVP for the tenth time and could not be happier. Over the past year I've been looking last XAML into the web stack and Microsoft has graciously moved me from a Data MVP over to an ASP.NET MVP. This doesn't mean I won't be sharing on Silverlight, WPF or data technologies; it's just a reflection of what I am working with now.
I want to thank everyone in the community for following me and reading my blog over past year...you're the reason I've been renewed again and I sincerely appreciate it!
I've spent the better part of six weeks building the new AgiliTrain website and its been quite a lot of fun. Of course if you have been reading this blog for long you know that I usually take a personal project like this as an opportunity to learning something new. In this case I did three things I haven't done on a personal project before:
I've been itching to use ASP.NET MVC on a project but until the beta arrived I didn't want spend too much time with it. Of course as you probably know, ASP.NET MVC released a RC yesterday so its pretty close to being done. I am still on the Beta until they RTW (release to web) ASP.NET MVC. Don't want to retrofit it twice.
I am working on a hybrid ASP.NET MVC and MVC Dynamic Data project. To work on it I started with the MVC Dynamic Data project assuming this would be a Dynamic Data Project and an MVC project. As Scott Hanselman recently posted, you can mix and match pretty easily so the code was working but I was missing an important piece of functionality in Visual Studio:
My project wasn't being showing these items (or other menu options specific to MVC apps). I suspected it was some magic in the project file so I opened it up in my favorite editor:
In response to some requests that I have received, I decided to write a several part blog on some of the techniques I used in developing Wildermuth.com. In this first example, I am going to discuss the use of LINQ and data in my site.
In moving from www.adoguy.com to www.wildermuth.com, one of my goals was to use LINQ as much as possible to see the travails of using it on a real project. I have done a lot of small samples with LINQ but did it hold up for real work? Suffice to say I am pretty impressed (though whether a blog is 'real work' is up for discussion, but its a better exercise of the technology than my samples had been).
When I say LINQ, I want to be specific. LINQ to me really is "Language Integrated Query". The data store behind is a secondary discussion and whether the Entity Framework, LLBLGen Pro, or nHibernate, I really wanted to make sure that the way I queried data in the C# code was LINQ. I was hoping to avoid dropping down into SQL as much as possible.
Now that the change to Wildermuth.com is complete I've gotten questions about broken links and such. I am keeping adoguy.com around and redirecting (permanent) the links so that old links aren't going to break. I don't plan on keeping it forever but for several years you can be sure. Its worth keeping them around.
I didn't just do a quick and dirty port to a new CSS look and feel though. This was a conversion of the old code. I don't use a blog engine but write my own code, mostly as a test bed for new ideas. What was it this time? Two thinks significant changed: Entity Framework/LINQ as the data access and the ASP.NET Routing Framework instead of .aspx links. Let's take these one at a time:
The use of the Entity Framework and LINQ was pretty straightforward. I used LLBLGen Pro in my old site to do the data access and it held up great. I only switched so I could test out the Entity Framework on a production-ish system. Not because of any limitations in the old code. Creating a model with the Entity Framework was a snap. My data is not complicated so I didn't have any complex scenarios. The only think I did do was change the collection names from singular to plural. Being able to use LINQ to do my queries, search and paging was just spectacularly useful. I am completely in the LINQ camp now.
In case you didn't catch it, I participated in a webcast called geekSpeak. This webcast was hosted by Glen Gordon and Chad Brooks. The topic today was "Silverlight and Line of Business Applications". While geekSpeak's usually focus on hands-on examples of creating code, we took a different tact today and discussed the larger topic of where Silverlight fits in the development ecosystem (at least Microsoft's ecosystem).
For my money, the real benefit in Silverlight is for applications that cross the firewall. This means Line of Business applicaitons are really for B2B and B2C solutions. Unfortunately, what I hear from the community is that people see Silverlight as a solution for porting their desktop and traditional 3-tier applications to the web. Is this a good idea? I don't think so. The problem is that desktop development usually involves business objects that tend to have a direct connection to the database. Moving these sorts of applicaitons to the web means that you need to create an extra layer of communications and serialization. There is a cost both in development and performance for these extra layers.
Quick fix for a problem that was haunting me today:
If you upgrade an ASP.NET 2.0 app to 3.5 and have .xaml files in your project that are part of a Silverlight 1.0 or 1.1 project, the conversion wizard converters them to Build-type: "Page" and adds a custom build for building the WPF files. If this happens you'll get a cryptic error:
"error MC6000: Project file must include the .NET Framework assembly 'WindowsBase, PresentationCore, PresentationFramework' in the reference list."
I recently was talking with a prominent developer in the Microsoft community as they were creating a new version of their website. They had used a code generator to create most of the code on the new site which I thought was cool, but I immediately wanted to know how much functionality was included. As I talk with other MVP's as well as Regional Directors, it seems that I am in the distinct minority. wildermuth.com is written almsot completely as custom ASP.NET code. Sure I used some components and started with someone else's HTML template, but most of the code is still C# to do much of the heavy lifting. Most of the people I talk with use community use pre-packaged systems to host their sites (including Community Server, DASBlog, etc.).
Why do I keep all that custom code? Mostly to allow me to try out new web techniques. I am facinated by CSS and like to learn how different sites do what they do. I also like to add new technologies as I can (e.g. Silverlight, LLBGenPro) as I learn them.
So what is interesting about wildermuth.com? Like most web sites, wildermuth.com is backed with a database. I store each rant, talk, code example (et al.) in a database. Much of this content is old. My first Rant was created back five years ago. Then the site was ASP and the database was a local Access database, and the website name was even different (comguru.com but I abandoned that name years ago...I was never really a COM Guru, more like a persistent hack but that's a story for another day). Here's what an early version of wildermuth.com looked like (via archive.org...some images are missing):
I've reworked my web site. It was looking a bit more like the uniform of a NASCAR driver than a web site, so I reworked the layout to make it cleaner. I admittedly stole many of my ideas from other web sites and templates I saw.
The other reason for the change was to eliminate ViewState. I noticed my pages ballooning from the sheer size of the HTML that was being generated, much of it as ViewState. I've eliminated ViewState in almost every case. For example, the size of the HTML of my home page was reduced from 134K to 48K. That's just HTML size, not images...so the real size change should be even more dramatic.
Let me know what you think and if you find anything not working. Thanks!
I am delving into WCF and AJAX (not at the same time) lately so I wanted to see if they were compatible. According to this whitepaper on ASP.NET (follow the link and scroll down to "Support for WCF Web Services"), the RTM of AJAX does not support WCF. It seems they removed it so they could make it work better in a later release. The promise is that by the Orcas release of VS, they will be compatible.
This further cements my opinion that releasing .NET 3.0 without FULL tool and compatibility is nonsense. Without a good across the platform support (e.g. WCF and ASP.NET stack working well together), a workable WPF editor (Cider is horribly broken currently...change the default editor for XAML to XML, you'll be happier), and projects that actually compile out of the box (WPF projects don't compile currently without some hand-editing of the XAML). Microsoft has always been about tools more than technology, that's why I've been with them so long. If we need to cruft together a bunch of installs to make stuff work, I'd be doing that in Java and Linux.
Until The ServerSide .NET can post the sample code, I am posting it here
I've blogged before about issues with the SqlDataSource. I've crufted up an example of the problems that can be downloaded here (with usual caveat of changing the connection string in the web.config to point to a DB with the Northwind database).
There are three basic issues:
Big thanks to Scott Guthrie in championing the Web Application for ASP.NET 2.0! I love using the old ASP.NET model (instead of the ackward Web Site project). I have now completely converted to the new format and I am very happy with the way it worked in almost every way.
On Fritz Onion's blog, he mentions that the manuscript for Essential ASP.NET 2.0 should be done by Monday. I am itching to get a copy of that book when it comes out.
I've been scratching my head at the ASP.NET 2.0 TreeView control. This control is meant to show a tree of items and each item can have a link to it. For example, this is what I use for my menu on the left of the page.
But it didn’t work. What was happening was that the control expected to navigate away from the current page, so selecting the item in the control did not matter. It simply ignored the “selection” process.
I was helping a friend out this evening trying to get a simple GridView working with a HyperLinkField from a database result and we ran into an interesting security feature that people might run into:
If you add a HyperLinkField to a GridView's Columns to allow a hyperlink in a column (pretty standard), it will create hyperlinks unless the URL starts with something other than http:// and https://. In our case, his DB has an URL of:
As some of you know I lost the screen on my main laptop (HP ZD8000, a lovely machine at 13 lbs) so I sent it into support where they are going to fix it but take 2 weeks to do it. I took over my old laptop from my dear Tricia to try and make it work for a while.
To simplify her world, the laptop only had XP Home on it. After getting the 3,000 things installed I needed to in order to work on my current project I am going to have to upgrade it to Professional. The problem? ASP.NET 2.0.
I am working on a project using the VS web server (not IIS would would have been an obvious Professional requirement). But I started to get the dreaded "Unable to attach. Binding Invalid Handle" error when trying to debug. Digging deeper it seems that it needs the VS Remote Debugger to work to debug in the VS Web Server (don't ask me why...it *just* does).
This is freaking huge in my opinion. It seems that all the fuss about how hard ASP.NET 2.0 has made it for many of us has gotten through to the team (yeah!). You can download the Preview here:
According to this post (this highlights my belief that MS is discouraging DataSets enough though they are using them everywhere (e.g. inside DataSources)). SInce Typed DataSets don't work out of the box with ObjectDataSources, we are left with three uncomfortable solutions:
The Partial Class solution may be easiest, but it is still some magical mix of parameters that will make it appear in the ObjectDataSource configuration dialog. I hope to have a better solution soon for this, but don't count on it.
I've been working on a problem for a client's project. We are doing pretty raw RAD design for a small intranet project so I thought, hey let's just do SqlDataSources to get the pages up and running fast. This works fine *if* we don't want any concurrency.
Let me repeat that, this works fine *if* we do not want concurrency.
The problem lies in the fact that we have columns that are null-able (pretty common in schema design). The concurrency that is generated by ASP.NET 2.0's SqlDataSource does not do the same concurrency (e.g. WHILE foo = @foo OR (foo is null and @foo is null)) that Typed DataSets and CommandBuilders have done for several years.