Thoughts from Dan Miser RSS 2.0
 Friday, December 14, 2007

Things I learned this week (sorry, Carl!):

  • The Cisco VPN Client software is very fickle. In order to upgrade from 4.8 to 5.0, you need to uninstall and install, with reboots to be found everywhere.
  • Installing an entire slew of MS updates is usually a good idea to keep your system up to date.
  • Even though your computer works fine at home, you can't rely on it working the same way when you get to work. For example, you might have internet access at home with no problems, but when you get to work, traffic over port 80 will suddenly stop about 5 minutes from the time you power up. https, ftp, email, IM, and everything else will continue to work just fine. Just no http traffic over port 80.
  • 5 minutes is not a lot of time to conduct google searches to find out what's wrong.
  • MS System Restore is implemented about as horribly as anything I've ever seen.
  • After running System Restore, the problem does not go away.
  • To make matters worse, System Restore totally hosed my Office install where it deleted a bunch of files from MSOCache, thereby causing my Office products to not be able to launch properly, or even uninstall.
  • After copying missing files back to MSOCache, all of the Office applications claimed they needed to repair installs upon launch. Every time.
  • MS has really good directions for how to manually uninstall Office 2007.
  • Seconds before doing a complete wipe of your system, it's a good thing to double check with friends who have Google-Fu.
  • It turns out that c:\windows\system32 has 2 files: vsdatant.dll and vsdatant.sys. These files get linked with ZoneAlarm a lot in google searches, but they are also used by the Cisco VPN Client. Something in the Cisco (un)installer caused rogue versions of these files to be left in my system. Rebooting to Safe Mode to clean these files up (along with the registry entries) finally got things back to normal.

And that, my friends, is what I learned this week. Now where's that next Monday's episode?!?

Friday, December 14, 2007 9:38:47 AM (Central Standard Time, UTC-06:00)  #    Comments [1] -

 Monday, December 10, 2007

At the risk of another "Me, too!" post, I thought I'd highlight several links that I have found to be helpful, and for a value-added bonus, talk about why this release matters to me. Back in the day (oh boy, does that make me sound old!), I learned how to program for the Internet by using straight HTML and Delphi to create CGI and ISAPI extensions. In order to do this, you needed to be quite aware of how the actual protocols worked, and what to do to make things behave as you'd expect. I stayed with web development up until I was using COM objects (again, written in Delphi) from an ASP page. After that, I wasn't into the web development scene much on a full-time basis.

ASP.NET 1.0 and 2.0 came along, and I found them to be quite daunting. It seemed as if it was framework built upon framework, layered with add-ins to do what I thought used to be simple things.

It appears to me that there has been a resurgence to move away from the barrage of constant abstractions, and to instead embrace the simplicity of the web (see the popularity of REST, Rails, and the buzz around ASP.NET MVC for some examples of this).

So for me, the reason I am excited is that not only can I once again utilize my knowledge about how the web works, but I can use it in new ways that will make my applications even better (e.g. TDD, scaffolding, etc.). At any rate, here's the set of links that I think matter for ASP.NET MVC:

Monday, December 10, 2007 2:40:56 PM (Central Standard Time, UTC-06:00)  #    Comments [0] -
.NET | ASP.NET
 Friday, December 07, 2007

I wanted to attend CodeMash last year, but waiting until the last minute worked against me. This year I made sure to commit to the event early, so I just signed up and got my hotel reservations sorted out. The sessions look to be pretty deep for a smaller conference, and I'm excited about going there to talk shop.

If you'll be going, drop me a line via comment here, and we'll be sure to sit down and have a beverage or 2. If you're in the Milwaukee/Madison area, and want to chat ALT.NET, it might be a good place to formally plan and launch the Milwaukee meetup.

Hope to see you there!

CodeMash – I'll be there!

 Monday, November 26, 2007

If you see an error like the following:

MSB6006: "NCover.Console.exe" exited with code 1. in build.proj(93, 3)

be sure to check that you are using the correct version of CoverLib.dll. In older versions of NCover (e.g. 1.5.8), by default, this dll should be registered every time the NCover task is run. I haven't found that to be true, though. I had an older version of NCover installed somewhere else on the build machine, and I kept on having my build fail because version 1.5.8 of NCover.Console.exe was loading version 1.5.5 of CoverLib.dll.

By manually registering the correct version of CoverLib.dll, I got the build working again.

Monday, November 26, 2007 10:21:48 PM (Central Standard Time, UTC-06:00)  #    Comments [0] -
.NET
 Tuesday, November 20, 2007

I can't think of one good reason for anyone to ever use System.Transactions.TransactionScope. There have been a lot of positive articles written about this class over time. I don't want to link to any of them because then you might be tempted to believe that this class is actually useful - as I did. I wanted to believe. I really did. Then I actually used it.

About 6 months ago, I tried to use TransactionScope, and things were great. I developed the system and had no issues. Then, when deploying to a client, I found out that it doesn't work with MSSQL 2000. I thought the requirements were ironed out that we were using MSSQL 2005, but it turns out that wasn't the case after all. Sure, there are ways to get it to work with MSSQL 2000, but at that point, I figured I'd just use the SqlTransaction directly.

Fast forward to today. I see MSSQL Compact Edition 3.5 is shipping, and it claims support for TransactionScope on desktop applications. Perfect! However, my unit testing shows that connections won't enlist in the transaction when using TransactionScope. To make matters worse, TransactionScope behaves differently when using MSSQL 2005 and MSSQL CE. So much for the ubiquitous advice of  using TransactionScope in unit tests.

My advice? Feel free to use TransactionScope if you will only ever hit MSSQL 2005 on the backend. Even then, I would triple check that it works properly because I have lost all faith in this class. As for me, I plan on ignoring this class completely due to the ill-implemented effort.

Tuesday, November 20, 2007 10:36:12 AM (Central Standard Time, UTC-06:00)  #    Comments [0] -

 Friday, November 09, 2007

Here is my quick and dirty laundry list of issues that I've been having with MSBuild over the past few days.

  • You can't detect which target is being executed, therefore conditional execution of tasks cannot be driven by targets. Instead, you need to start a crazy chain of adding targets and updating properties and adding the new target to DependsOnTargets for the original target. No wonder the build file becomes unwieldy so quickly.
  • It is very unintuitive and cumbersome to update property values. If I want to set a property one way in one case, and another way in a different case, it is not easy. Besides, the syntax for the CreateProperty task is way more complex than it needs to be to simply update a property.
  • Brutal gymnastics are required to get around customizing build properties outside of the confines of the Configuration mechanism for a given project. For example, let's say I want to change the DocumentationFile parameter used in csc.exe, or change the NoWarn directive. If you're calling an MSBuild task on your solution, you need to specify those command-line parameters as /p: parameters from the command-line or track what you want to do and add the actual command-line parameters to the Properties attribute. It should be as simple as overriding the default build properties that exist in the csproj file, but that doesn't work.
  • It lacks a way to list descriptive tags for all defined targets (c.f. "nant -projecthelp").

Apparently, I'm not the only one who sees this as a problem. I think Martin's idea of using a lightweight/script language to control the build is the way to go. Granted, I'm coming to this conclusion 4 years after he is, but the point is still valid today. I'd like to have more language elements in my build process to deal with branch, loop and flow so I can react better than I can with an XML file.

My bottom line: MSBuild may be a good tool for VS.NET to use because it can tightly control the format, but it is not a generic solution for controlling a medium-to-big size build process.

Friday, November 09, 2007 10:45:29 AM (Central Standard Time, UTC-06:00)  #    Comments [2] -
.NET
 Thursday, November 08, 2007

I've had some conversations with people about the label of ALT.NET. They are of the opinion that it causes controversy by setting up the "elitist" vs. "everyone else" mentality. This is not a new observations (see here and here, e.g.).

I'd like to propose that the divisiveness of the ALT.NET moniker be abolished as quickly as possible. To that end, my proposal for the name is Pragmatic.NET. It's both a state of mind and an homage to the Pragmatic Programmer series that touches on several of the topics important to this group.

Discuss...

Thursday, November 08, 2007 11:54:09 AM (Central Standard Time, UTC-06:00)  #    Comments [2] -
.NET

I'm more than a little disappointed that I missed the ALT.NET conference in Austin, but I'm extremely happy that it looks like the movement has crystallized and gained enough momentum to be a legitimate option for .NET developers. Steve Kronsnoble made an analogy to the Agile Manifesto, where it took a bunch of informal participants and related ideas and turned them into industry standards. Hopefully, when looking back on this event years from now, people will be able to identify this as the genesis of  .NET.

I really like the idea of ALT.NET, and it maps to discussions I've had with many developers about trying to find a "Garden Path" of .NET development. Some percentage of .NET developers will use whatever Microsoft tells them to without question. That's fine, but that's not how I think. I like to grab the best technology no matter where I find it (Open Source, other languages, etc.) . I want to talk about things like NHibernate, Spring.NET, Subsonic, the new ASP.MVC framework, Domain Driven Design, Test Driven Design, Unit Testing, and on and on. To me, that's the excitement of ALT.NET.

To do my part, I'd like to start a discussion on where and when to hold a local Milwaukee version of this OpenSpace conference. If you're passionate about .NET development and want to help shape this new movement in the Milwaukee area, please leave a comment so we can find a way to move the ball forward.

Thursday, November 08, 2007 10:02:04 AM (Central Standard Time, UTC-06:00)  #    Comments [5] -
.NET
 Monday, November 05, 2007
I've been working more with data-binding and the ObjectBindingSource component that I wrote about here. Here is some stripped-down sample code to help investigate more data-binding concepts.
class Customer { 
  int Id;
  BindingList Orders;
}

class Order {
  int OrderNumber;
  Product ProductInfo;
}

class Product {
  string Vendor;
  Product Self;
}
Assume that we want individual GUI components for the Customer object, and a grid to display the associated orders, with the related Product information displayed along with the Order. Here are some quick pseudo-code tips to get things wired up properly.
  • CustomerObjectBindingSource.DataSource = typeof(Customer)
  • CustomerObjectBindingSource.BindableProperties.Add("Orders"). (If you don't do this, the detail ObjectBindingSource won't work later on.)
  • OrdersObjectBindingSource.DataSource = CustomerObjectBindingSource and OrdersObjectBindingSource.DataMember = "Orders"
  • OrdersObjectBindingSource.BindableProperties.Add("Product")
  • DataGridView.DataSource = OrdersObjectBindingSource
  • Modify the DataGridView column for Product by setting:
    • column.DataSource = ProductsBindingSource
    • column.DisplayMember = "Name"
    • column.ValueMember = Self
  • **IMPORTANT** - Use the same object references everywhere for the product objects (i.e. in the DataGridView column and where you access them in your code). In the sample, I use the productBindingSource component for both the lookup in the grid and the way to lookup individual Product instances. Another alternative that I tested is to use a singleton class for the collection. If you don't do this, you will get the dreaded "DataGridViewComboBoxCell value is not valid" error when the grid tries to populate the Product value.

For concrete details, download this project. I look forward to your comments.

Monday, November 05, 2007 11:26:17 PM (Central Standard Time, UTC-06:00)  #    Comments [0] -
.NET
Navigation
Archive
<December 2007>
SunMonTueWedThuFriSat
2526272829301
2345678
9101112131415
16171819202122
23242526272829
303112345
About the author/Disclaimer

Disclaimer
The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.

© Copyright 2008
Dan Miser
Sign In
Statistics
Total Posts: 306
This Year: 21
This Month: 0
This Week: 0
Comments: 604
All Content © 2008, Dan Miser
DasBlog theme 'Business' created by Christoph De Baene (delarou)