Tagged with Programming
Very short post today, but wanted to share something that happens more than I'd like to admit. I work for some clients who use TFS and when I can't in through their VPN I need to zip up my files for them to check-in manually. It's not fun (I miss being able to create a change set in Mercurial or Git). When this happens I need to have a quick way of copying all the files in a project that aren't marked as read-only. Robocopy to the rescue:
robocopy %1 %2 %3 /S /XA:R /XD obj bin packages backup _UpgradeReport_Files /XF *.suo *.vssscc *.user *.vspscc
This allows me to copy all the files I'm working on while skipping the temp files (e.g. obj, bin), package chagnes, backup files and upgrade files. Hope this helps anyone else that runs into this.
After spending time creating my own caches of reflection data I found the NHibernate type information to be more complete and faster. Go figure. At this point I am using the SessionFactory's GetClassMetadata and GetCollectionMetadata to return IClassMetadata and ICollectionMetadata interfaces. So far this has given me every piece of runtime information I need and means that I don't need to do any nasty (and potentially fragile) walking through the property interface of the context object. Whew...
So to refactor my GetResource and CreateResource calls. GetResource is easy. GetResource passes in the query and the full type name (though the full type name may be missing in some cases). The query it passes it must resolve to a single result. That means I can simply execute the the query and if it returns more or less than one result, return an error. Once I have the result I can just check it against the full type name (if it was passed in) and return the value.
Ted Neward's blog is one of those blogs that *everyone* should read. I am always surprised when I hear of .NET guys who don't know him. I think because he's been firmly in all camps at the same time, he often gets dismissed for "being a Java guy". Too bad for you that don't know better. Subscribe today, read the backlog, learn and grow as a developer.
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.
I have been diving pretty deep into ADO.NET Data Services (see an upcoming article about ADO.NET Data Services and Silverlight 2 coming soon). I've been looking at the story around non-Entity Framework models through a Data Service and thought that NHibernate through a Data Service would be a great example.
So I tried to get it to work with the NHibernate LINQ project. The example model that the project uses is a simple Northwind model. I thought I'd just take that model and expose it via ADO.NET Data Services. I crufted up a simple Data Context object for ADO.NET Data Model but it didn't work. ADO.NET Data Services was complaining about the fact that the end-points (e.g. IQueryable<Customer>) was pointing at an Entity. This was a bug...a but in ADO.NET Data Services. I hacked together a fix to get around it (and reporting it). If you're interest, the problem is that if the key of the entity is in a base class and *not* named "ID", it fails to find it. Again, this is a bug not a feature of ADO.NET Data Services.
Now that it was working, now what? I wanted to be able to make changes to the model but the NHibernate context doesn't support the updating interface: IUpdatable. (Though I sure wish they'd rename it IUpdateProvider to match the IExpandProvider interface). If you're not familiar with this requirement, note that only the Entity Framework currently support the IUpdatable interface (and is in fact implemented inside of ADO.NET Data Services not directly in Entity Framework). This means that DataSets and LINQ to SQL do not support it either.
Pete Brown called me out to answer the next round of "what about you" questionnaires floating around the blog-o-sphere. So here's my take:
How old were you when you first started programming?
When I teach Silverlight 2, I stress an important lesson that I thought that we (as developers) had learned the importance of linkability of the web. Early usage of Flash was the first time I noticed this. A number of those sites would create nested functionality that never changed the URL. If the URL doesn't change, i can't bookmark it. Most Flash guys learned their lessons pretty quick, but now I am inundated with AJAX driven sites that try hard to not to do post-backs. That's cool, but if the URL doesn't change I can't link to it.
I've noticed this happening a lot with support sites. The first time I saw with an AJAX site was using the Intersoft's Developer Portal (http://www.intersoftpt.com). They treat the developer to a desktop-like experience, but if I can't send a link to my other developers for the latest patch, why bother making it on the web?
The latest is the game Spore's forums. Trying to help a friend figure out why its crashing, I found some good posts on workarounds but the site's address is always http://www.spore.com/forum. What's the point?
I am surprised when I talk to developers these days and they don't know who Sara Ford is. She's responsible for CodePlex and many open source initiatives at Microsoft. In addition, her blog is an excellent source of information on Visual Studio tricks and features that most of us have never noticed. It is well worth a read. Just announced today, her blog is now available in Russian and Spanish so if English isn't your native tongue, you're in luck there too.
Wonder how I get someone to translate my blog into other languages ;)
I've spent a lot of time the last few weeks looking at some of the new buzz words in software development. Domain specific languages, dynamic languages, TDD, DDD, *DD, etc.. Most of these ideas have definite benefits to the work of software development but I think they miss the mark on what is really hard in software.
In most projects I've worked on the past twenty some-odd years, the hard part is not how to architect a project, not how to tune a database and not how to eke out every CPU cycle of a function call. In fact the hardest part has always been in understanding how a business does business. There are many names for this but I like to think of this as domain specific knowledge. It's the time in the meeting room with the business veterans (stakeholders of one sort or another) that understand how it really works. Whether that is how freight is shipped across country, how users register with forums or how those scanners at the grocery stores actually work; in all cases these stake holders already know how they do or want to do their job. It is our work as developers into transitioning that into actual software.
Eric Evans talks about this in his Domain Driven Design book, but I think some readers of his book seem trapped into thinking that the magic of the domain is the top-down design of a system. In my opinion they are missing the point. Turning domain knowledge into a system is hard work, no matter what design methodology you use.
Jeff Atwood is up to his old tricks. He's succinctly reminds me of why I read his blog so religiously (though like religion, I tend to be a cynic and not agree with everything he says). I read the McConnell books a billion years ago and have forgotten about this excellent analogy of painting the dog house.
Essentially it is saying that building a small project may require you to make a lot of shortcuts if time is of the essence. It is ok to make these shortcuts knowing that we will need to re-paint the dog house one day. Fido can live with rusty nails and flaky paint. On the other hand if you are painting a 747, you better get it right.
I use a Dish Network satellite dish for my TV. They pushed an update last week to all their subscribers. This new feature is a great idea: if an HD channel is available for a channgel (e.g. ESPN, Local Channels), tune the HD channel instead of the non-HD version. Normally that would be perfect...except...not all HD versions of channels have the same programming.
For example, Discovery channel ahs an HD version they call Discovery HD Theatre. They are actually two different channels with two different programming. For example, two of my favorite shows are not shown on Discovery HD because they aren't in HD (Discovery HD is completely HD, they never show non-HD shows (AFAIK)): Dirty Jobs and Mythbusters.
The way they implemented the feature is that in their guide it shows both channels and lets you pick which one you want. For most users of the dish this works fine. They can pick which channel they want.
After reading this interesting article by Pablo Castro, I have to assume that the real purpose of using Async Execution is for specific use-cases when you need to fire off multiple concurrent queries in service situations (e.g. ASP.NET, Web Services or Windows Services).
There are several interesting observations in this article:
My newest DevSource article is live. It is about how to write Windows Live Messenger Addins with .NET. Check it out
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:
In this assembly, the designer created an app.config and a Settings.setting object. All sounded good. So in my ASP.NET 2.0 project, I setup the connection string in the web.config and called it "MyConnection". This all worked until I deployed it to a server, when all hell broke loose. After deployment, my code that did *not* use Typed DataSets (mostly DataSources) worked fine with my new "MyConnection" connection string...but...
Everywhere I used the Typed DataSets it was failing to connect to the database. When I looked at it it seems that the Typed DataSets were using the connection string I used on my dev box...but no app.config to be seen. How was it getting that bad connection string? Well it seems that the connection string information is being embedded as the "default" connection string to use if it can't find the connection string in the configuration. Ok, this is bad...I'd hate for my assembly to actually have stuff like my password embedded in it, but I doubt that happens. I was using integrated security so I haven't tested the password embedding yet.
But what is strange is the connection string was in the web.config. What gives? Well the Typed DataSet satellite assembly named my connection string with namespace and setting prefixes. "MyConnection" became "MyApp.Properties.Settings.MyConnection" because the serialization of the name includes all of that. Yeech...
Usually I don't like to link to mailing list archives, but this is an excellent reply to a question on the Advanced .NET Mailing list. Ian explains this better that I have read before. He covers why you would choose one over the other for the security and perfomance implications of each. It's a must read IMHO.
I submitted a bug to Microsoft's ASP.NET team that objects added to the Component Surface (right-click and pick "View Component Designer") aren't visibile to controls thereby breaking 1.1 data binding. Here's the response I got: They closed it with:
Thank you for submitting this issue. At this stage in the Whidbey product cycle, we're taking very few changes into the product. We have evaluated this issue and will not be able to investigate it before release but we’ll reconsider it for the next version of the product at a future date. To help us better evaluate this issue, we would appreciate if you would send email to email@example.com with the FDBK ID of this issue in the subject line so we can contact you later, if necessary. For more information, please refer to the announcement on the MSDN Product Feedback center at http://lab.msdn.com/productfeedback.
The Web Platform & Tools Team
As many of you might not know, I am not at the PDC, but am interestingly watching to see what comes out from it. Usually at the event times, everyone blogs too much about what they like and don't like. Everyone wants to be the first out the door with some news from a keynote. So I am layng low and letting all that happen without me. On the plus side, I can now talk about some things that I've had the opportunity to play with for some time (now that they are public knowledge and I am not hurting any NDA's):
I find it unfortunatle that Microsoft has made is way too difficult to write your own DataSource enabled controls. Deriving from DataBoundControl, but it still does not seem to be a way to synchronously get the data from the DataSource. In a DataBoundControl control you can get the DataSourceView like so:
DataSourceView view = this.GetData();
I have so many SQL Server instances on my local machine others in my home office that I wanted one place to start and stop them all. I liked the start-stop functionality in the SQL Server agent, but I have MSDE instances and SQL Server 2005 instances running too, so a single place to do it all from an icon tray was my goal. So here I've created a simple .NET 2.0 application. I would have done it with 1.1 to make it more accessible for users, but there were some features I needed in 2.0 to make the app work. So if you have the .NET 2.0 Framework installed, check out this new app to control multiple instances of SQL Server a mouse-click away:
It's not finished yet, but I am working on a Font Browser using Avalon. It's fun to work with XAML and code-behind, but without splitter or treeview controls its hard to make something really fun. I am also working on a database browser with Avalon, but until I find a tree view that project is dead.
I will post the font browser this weekend.