I have this awesome little ADO.NET code generator called .netSavant.  It analyzes your stored procedures and generates an optimized wrapper class that encapsulates the logic for execution.  After using it myself for quite some time, I thought, oddly, that I could make a little extra cash from the endeavor.  Heh, sadly I was wrong.  Dispite a lot of interest, few people were interested in paying $50 for a visual studio addin that saved a LOT of time and buggy code.  Wierd, but whatever.

So, with mixed feelings I killed the project.  It simply cost too much money to maintain the website and merchant account for a product that only sold a handful of licenses over the 18-24 months.

I’m left wondering what to do with the project.  There are a few options:

1. Create a codeplex project
2. Host the source code myself
3. Release the addin as freeware (no source code)
4. Release the addin as freeware with sponsorship (uhg, gross right?) (no source code)
5. Leave the project inactive and move on to other exciting technologies

I’m wondering if I really want to spend more effort supporting the project as a whole, though with so much time invested, its hard to walk away from it.  Part of me would like to see more people use .netSavant, if only to justify the time I spent creating it.  I’d also like the challenge of updating some of the methodology used to generate the source code, and possibly provide some extensibility points to enhance the analysis features that it supports.

Perhaps some day .netSavant will be resurrected in a better form.  Until that time, thanks for your interest and support.

Joshua

While working on some application security requirements for a client, I came across this little nugget about cracking pgp passwords using a cloud.

Cracking Passwords in the Cloud

It’s interesting to see how easy it  has becomes to brute force passwords using distributed computing. While brute force attacking passwords for the average person is still time-prohibitive, even with a cloud, the ability to reduce password cracking times from years to weeks is impressive.  Cracking performance will continue to increase as distributed computing becomes cheaper, faster and more widely adopted.

Take a look at the article and think of how this could affect your data:  Cracking Passwords in the Cloud

If you haven’t started to really focus on application data security, perhaps you should…

I’ve been working on this latest release of .netSavant for some time now, and released it on 11/23/2008.  Its a pretty substantial update, though it may not look so much so at first glance.  There are a few things of note that are included in this release:

• Created Tools Options Page options to select which methods will be implemented for statements (stored procedures and inline sql).  This allows greater customization of the code that .netSavant generates by excluding methods that you never use.  Personally I never use DataTable or DataSet objects, so I have .netSavant configured to exclude these methods when generating my code.
• Simpler Unit testing support is achieved by not including code that you have no intention of using.  See the point above.
• Updated the VB.NET and C# code generation framework to format the generated code a bit more cleanly.  Who likes messy code right?
• Updated VB.NET generated code to use using statements rather than Try blocks for objects that implement the IDisposable interface.
• Updated the database connection form to default to the SQL Server provider rather than forcing you to select it each time.
• Numerous bug fixes.

I highly recommend upgrading to this version, visiting the Tools > Options page to set your preferences, and regenerating any legacy .netSavant code.

Enjoy!!!

At some point in their career everyone who creates ASP.NET applications has had issues with their site throwing exceptions that aren’t trapped.  We end up displaying a friendly error page at best, and at worst display the yellow ASP.NET error screen of death.  Generally speaking it’s best practice to configure your ASP.NET application to use friendly error pages so that your users aren’t presented with an exception and stack trace that are meaningless to them.

But how do you find out what exceptions are being thrown by users who are not you?  Over the years I’ve created many versions of the same type of code to handle these situations, so last night I created a project on codeplex that I’m calling sigh.net.  Essentially, sigh.net is a provider based unhandled exception handler for ASP.NET applications.  You can download the source at http://www.codeplex.com/sigh.

It’s extremely simple to use and doesn’t require you to change or add any code to your application.  I currently have an email provider created and am in the process of creating a SQL database provider.

Enjoy!

I’ve wanted to work with Silverlight for some time now, though I’ve not had a use for the technology until recently.  I wanted to create tutorial videos for .netSavant to help people learn a bit about the product.  After a bit of searching I found a fantastic code project article written by Karl Shifflett that walks you through the entire process of not only creating a high quality screen capture tutorial, but publishing it as a streaming silverlight video.

Click Here to read the article

To date I’ve only created and published a single tutorial for .netSavant.  I’ve several more planned that will hopefully be a bit more polished as I become more comfortable talking, effectively, to no one.

http://www.dotnetsavant.com/Overview/Tutorials.aspx

Enjoy!

As a followup to my system.nullable vs. tryparse entry, I’ve decided to publish the nullable parser code that I use in the data access system of .netSavant.

Download the C# file (in txt format)

Enjoy!

I’m proud to announce the release of my new code generating addin, .netSavant.  You can download the release candidate on the website from our download page.

The addin will help you create robust ado.net code with an intuitive drag and drop interface.  Additionally it will generate best practice implementations of three (currently) system interfaces:

• System.IEquatable<T>
• System.IDisposable
• System.ICloneable

Currently I am working on the example code that will help to explain how to best use the ado.net code that is generated.  I’m also working on more and better F.A.Q. entries to answer those pesky little problems that come along with learning a new tool.

If there is any functionality that you’d like to see added to the addin let me know; I’ll entertain any reasonable request.

Enjoy!

You’ve struggled through understanding commands and toolbars, pulled your hair out deciphering confusing API’s, and scarred your neighborhood with red-faced screams of frustration as you debug unhandled exceptions that crash visual studio.  After weeks, months or yes even years polishing an addin you still aren’t finished until you create an installer program.

The installer projects available in visual studio make creating an installer a trivial affair; however there are a few things to consider when making an installer for an addin project.

The .addin file

When you create a new addin project in visual studio 2005 or 2008 you will have an xml file in the root directory of your application named YourProjectName.addin.  Opening this file will show you the base structure of the xml that among other things defines the location of your addin assembly.  The trick of installing the addin via an installer project is placing this file in an appropriate location on the user’s workstation as well as modifying the xml to point to the location where your addin is installed.

Addins for visual studio 2005 and 2008 are installed by placing the .addin file in one of several locations on a developer’s workstation.  These locations are managed through visual studio under the Tools > Options > Environment > Add-in/Macro Security options page.  Here you will find a list of paths that visual studio will investigate when it loads to locate various addins that you may have installed.

I caution you on modifying this list; most addins that are written will be installed in one of the default paths specified by here.  If you change these default paths you could easily lose access to any addins that you already have installed.

Where to put your .addin file

For my addin, .netSavant, I use the following line of code during my installation process to generate a file path that the .addin file will be saved to:

Path.Combine(Environment.GetEnvironmentVariable(“ALLUSERSPROFILE”), @”Application Data\Microsoft\MSEnvShared\Addins\DotNetSavant.AddIn”);

This will generate a string value that looks like C:\Documents and Settings\All Users\Application Data\Microsoft\MSEnvShared\Addins\DotNetSavant.Addin (on my laptop).  Again, there are other locations that you could save the file to though I’ve found this one to be the most reliable as far as it’s existence on developer workstations, and being configured in visual studio (its included in vs.net by default).

One complexity to think of; If your user is installing on a non-english version of windows, I’m honestly not sure how to best compose the file save path.  I suppose I’ll have to deal with this eventuality eventually.  Until then I’m going to live in my quiet and warm happy place.

Creating the Installer Class

As with any installer project, if you want to perform some kind of custom installation action you’ll need to create an Installer class somewhere in your application.  This is as simple as creating a new class file and having it inherit from System.Configuration.Installer.  You’ll need to decorate your new class with the RunInstaller(true) attribute and override the Install, Uninstall, and Rollback methods.  These methods will be used to install your .addin file, remove your .addin file when your addin is uninstalled and roll back any installation tasks that you’ve performed if there is an error during the installation process.

Overriding Install

The most complex method of the installation process, this is where you’ll create your .addin file and save it to the path that I’ve mentioned above.

For .netSavant I store my .addin file in the root directory of my project and set its build action to “Embedded Resource”.  This way I can make simple adjustments to the file and it will always be available as a resource of the assembly.  This comes in handy during the installation process, specifically the Install method because I can access the embedded resource, modify the path defined in the Assembly nodes and write the xml contents to disk.

Since the release of vs.net 2008 I’ve updated my own installer to use a block of LINQ that looks something like this:

XDocument linqXmlDocument = null;
string installationPath = base.Context.Parameters["AssemblyPath"];
string addinResourceFile = Assembly.GetExecutingAssembly().GetName().Name + ".DotNetSavant.addin";

using (Stream resourceStream = Assembly.GetExecutingAssembly().GetManifestResourceStream(addinResourceFile)) {
    linqXmlDocument = XDocument.Load(XmlReader.Create(resourceStream));
}
var query = from assemblyNode in linqXmlDocument.Descendants()
    where assemblyNode.Name.LocalName.ToLower().Equals("assembly")
    select assemblyNode;

foreach (XElement assemblyNode in query) {
    assemblyNode.SetValue(installationPath);
}
string addinXml = linqXmlDocument.ToString();

Note the use of base.Context.Parameters["assemblypath"].  The base installer object gives you access to these values to access form information collected during the installation process.  In this case I’m accessing the path that the user specified as the installation directory for the addin.

Overriding Uninstall

When uninstalling your addin, it would be prudent to delete the .addin file from the user’s file system.  Its just common sense that when you uninstall something you should remove everything that was added to the users computer during the installation process.

Overriding Rollback

The rollback method is where you will implement any clean up code that will be run if the installation process needs to terminate before its completion.  Be aware that you’ll not know at what point in the installation process this method might be invoked by your installer package, so any cleanup that you perform should be wrapped inside of try blocks so that the rollback method can execute cleanly.

Back to the Installer Project

Now that you have an installer class it’s a simple matter to wire it up to your installer.  Make sure that your installer references either the build output of your project or the compiled assembly of your project directly.  Then, right click on the installer project and select View > Custom Actions.  You’ll see four folder icons labeled Install, Commit, Rollback and Uninstall.  Simply right click on a folder, click “add custom action” and browse to the assembly that contains your installer class.  Do this once each for the Install, Rollback and Uninstall folders to end up with a configuration that looks something like this:

At this point the installer project is configured to use the custom installation process defined by the installer class.  When the installer is run the .addin file will be successfully written to a legitimate addin path as part of the installation process.  Conversely it will be removed from the file system during uninstallation.

Potential Issues

I hinted earlier that non-english users might have issues installing the addin using my methodology.  This is because I hard-code part of the .addin installation path in English during my install process.  It will be impossible to guarantee that the paths specified by default in visual studio will always be in English, thus we have a potential localization problem to deal with.  Remember that if you don’t see your addin in the addin manager in visual studio you most likely saved your .addin file to a path that is not recognized by the development environment.

Another common issue that is easy to overlook; make sure that you’ve specified a valid path to your assembly in your .addin files’ Assembly node.  If this path is incorrect visual studio will not load your addin.

Enjoy!

Like many addin developers I create options pages in visual studio to handle configuration of my software.  While extremely simple to create these pages, it is not obvious how they should be configured to load with visual studio.  Additionally, the documentation for creating options pages provided by Microsoft describes in detail how to create options pages, though neglects to describe how to make visual studio recognize your options page control.

Fortunately this is extremly simple to wire up.

<?xml version="1.0" encoding="utf-16" standalone="no"?>
<Extensibility xmlns="<a href="http://schemas.microsoft.com/AutomationExtensibility" mce_href="http://schemas.microsoft.com/AutomationExtensibility">http://schemas.microsoft.com/AutomationExtensibility</a>">
  <HostApplication>
    <Name>Microsoft Visual Studio</Name>
    <Version>9.0</Version>
  </HostApplication>
  <HostApplication>
    <Name>Microsoft Visual Studio</Name>
    <Version>8.0</Version>
  </HostApplication>
  <Addin>
    <FriendlyName>.netSavant</FriendlyName>
    <Description>.netSavant is a powerful code generator for the .net framework and Visual Studio.NET.  For more information please visit <a href="http://www.dotnetsavant.com/" mce_href="http://www.dotnetsavant.com/">http://www.dotnetsavant.com</a> </Description>
    <AboutBoxDetails>For more information about .netSavant please visit <a href="http://www.dotnetsavant.com/" mce_href="http://www.dotnetsavant.com/">http://www.dotnetsavant.com</a> </AboutBoxDetails>
    <AboutIconData></AboutIconData>
    <Assembly>Path to .netSavant assembly</Assembly>
    <FullClassName>DotNetSavant.Connect</FullClassName>
    <LoadBehavior>1</LoadBehavior>
    <CommandPreload>1</CommandPreload>
    <CommandLineSafe>0</CommandLineSafe>
  </Addin>
  <ToolsOptionsPage>
    <Category Name="DotNetSavant">
      <SubCategory Name="Adapter Generation">
        <Assembly>Path to .netSavant assembly</Assembly>
        <FullClassName>DotNetSavant.Controls.AdapterSettingsOptionsPage</FullClassName>
      </SubCategory>
    </Category>
  </ToolsOptionsPage>
</Extensibility> 

You’ll notice that I added a ToolsOptionPage node under the root Extensibility node of a standard .addin xml file.  Here you can identify hierarchal categories that will be displayed as visual studio options pages.In this example I’ve added a top level options page called “DotNetSavant” with a sub category named “Adapter Generation”.  Similar to the addin node of the base .addin file, both Category and SubCategory nodes can specify a single Assembly and FullClassName node.  Set the assembly nodes’ inner text to the path of the assembly where your options pages control exists and then specify the fully qualified name of your options pages class in the FullClassName node and your options pages will load with visual studio.Enjoy!

One of the most frustrating things I’ve found when programming addins for visual studio is the inability to globally trap unhandled exceptions the way that you can when  authoring a windows application.  Essentially visual studio intercepts exceptions your addin throws that you neglect to handle.  The worst part is that you don’t get any information about the exception before visual studio crashes!  Its great that Microsoft gets a dump of the crash, but you’re left standing empty handed and scratching your head.

Generally speaking an addin framework should not allow an addin to crash the host application.  It points to either a design concept that I can’t comprehend, a significant oversight in the design of the visual studio addin framework, or simply some kind of interop issue that visual studio doesn’t handle well.

Short of making sure that every block of code in your addin that can throw an exception is wrapped in a try block we don’t have a good methodology for dealing with unhandled exceptions.  While this is a good thing because it forces you to write solid code it can be exceptionally frustrating to to debug unforeseen issues in a production environment.

I’m still looking for a good way to trap or instrument unhandled exceptions in addins that I write, especially in runtime environments.  If I find a good approach I’ll be sure to write about it.

Enjoy!