The ASPSmith's Blog

Some rants about ASP.NET by Steven Smith

August 2003 - Posts

Object Must Implement IConvertible with MS Data Access Application Block

Ran into this bug today.  I'm not the first, as a quick goole search found:

Google group thread.

Ted Graham also wrote about it, specifically for Access.

I think I'm close to finding the actual bug in the C# version of the DAAB, but I don't have time to totally fix it just yet.  However, I did find a workaround that I hope will help some folks.  I was calling a stored procedure like so:

return SqlHelper.ExecuteDataset(ConnectionString, "usp_ListAuthors", sqlArgs).Tables[0];

All I did to fix it was switch to another overload:

return SqlHelper.ExecuteDataset(ConnectionString, CommandType.StoredProcedure, "usp_ListAuthors", sqlArgs).Tables[0];

Simply specifying the CommandType fixed it.  I'm sure the other version has a bug in it - if you have the exact fix, I'd love to hear it.

Thanks!

Databinding Server Controls - Learned Something New

I was running into an issue databinding an ImageButton's ImageUrl property to a string comprised partly of literal text and partly of a string I was pulling from my ConfigurationSettings.AppSettings collection.  I was using the standard <%# ... %> syntax for the databinding, but the result kept showing my databinding syntax in the button's URL, rather than the actual value.  It seems that while you can do the databinding to the control property, it's all or nothing.  So if you want the string to be:
<asp:ImageButton ... ImageUrl=”/folder/<%# MyConfigVariable %>/Add.gif” ... />

Then you need to code it like this (VB):

<asp:ImageButton ... ImageUrl='<%# “/folder/” & MyConfigVariable & “/Add.gif” %>' ... />

Thanks a bunch to Andy Smith for helping me see the light.

Listening to: Command and Conquer - Hell March

"unexpected error creating debug information"

I keep running into this issue in my multi-project VS.NET solutions.  For some reason, something is locking the dll(s) in the /obj/ folder of library components.  The fix that I have at the moment is as follows:

  1. Shut down VS.NET
  2. Browse to the project in windows explorer
  3. Delete the /obj/ folder.
  4. Delete the project outputs (.dll and .pdb) from /bin (not sure this step is necessary)
  5. (can't hurt, might help) -- delete the project outputs from any other project /bin folders in the solution that is having issues.
  6. Restart VS.NET
  7. Rebuild
  8. Laugh the next time you hear that DLL Hell is no more in .NET...

Update: Just deleting /obj/ after closing VS.NET does it.  Ambrose pointed me to prcview.exe and that demonstrated that it is in fact devenv.exe locking the file, so it's VS.NET's own fault, not Index Server or anything else that is to blame.

Listening to: Disturbed - Remember

Caching Best Practices Article on MSDN website

My first MSDN online article was published this week: ASP.NET Caching: Techniques and Best Practices.  The first half is pretty much well-known info about caching in ASP.NET (at least, it should be well-known to anybody writing ASP.NET applications).  The tips and the best practice pattern are the real valuable parts here for everyone who already knows the caching capabilities of ASP.NET, since these tell you why you should use caching and how to do it the most efficient way possible, which aren't necessarily apparent from the docs.

Anyway, hope they help someone.

InfoPath Tidbit

InfoPath forms can only be viewed and filled out by folks who have InfoPath installed... or can they?  As it turns out, InfoPath .xdr files are really just CAB files.  This means you can use the 'expand' utility (in Windows 2000 and later, I believe) to pull out the pieces of the XDR file, one of which contains a definition of the form (actually, one .xsl file per form).  With a little search-and-replace or perhaps another XSL transform, it would not be too terribly hard to convert the input controls used by InfoPath into, say, web controls, allowing the forms to be displayed via ASP.NET.

Unfortunately, that would be the closest you could get InfoPath to .NET.  Although it can consume web services and is an all around very cool tool, it uses VBScript/JScript and ADO for all of its programmability.  You'd think 3 years after .NET hit the scene (publicly) that a brand new application would at least support the CLR, but noooooo.

.TEST Tool

James Avery wrote about .TEST, so I checked out their video demo.

It looks really very nice.  The automatic generation of white box tests, ability to add black box tests without resorting to code, and notification of violations of best practices all were very compelling.  The speaker in the movie needed to enunciate a bit better at times, and the UI looks like it could use some improvements, mainly by adding some additional columns instead of listing things like this:

25 / 2 / 94 / 92 (%)  Some tests that ran

It would be nice if each of those numbers were in a column with a header and a tooltip saying what it is and letting me sort on it.

Like James, I too didn't see anywhere to get price info.  I just registered with the site so I could get the free download.  After asking for some marketing info, it let me 'proceed' and I'm not grabbing the 42MB eval install.

More Posts