My friend Andy asked me a few minutes ago how to recover from inadvertantly deleting a Forms Designer generated .resx file. In order to recover from this unfortunate happenstance, I had him do the following:

  • Open the .csproj file in his editor of choice.
  • Locate the <File> element that references the .resx file.
  • Delete the element.
  • Close up shop and relaunch the project file in VS.NET
  • Open the form in the designer. The .resx file will be regenerated by the IDE.
  • Drink a beer.

After completing those afformentioned steps, the sun shined, the birds sang, and all things were good. 🙂

I’ve started to work with Visual Studio 2005 Beta 1. I installed it into a Virtual PC 2004 VM running Windows XP SP1a. In the process of trying new things out, I discovered the new ASP.NET Web Site Administration Tool. This is a web app that allows for easier configuration of Security, Profile, Application, and Provider settings. It was with the provider settings that I encountered a problem.

ASP.NET 2.0 is packaged with two providers for ASP.NET settings, AspNetSqlProvider and AspNetAccessProvider. The corresponding database for AspNetSqlProvider is created with the aspnet_regsql.exe utility. This utility only creates the database, tables, views, and stored procedures. This utility does nothing about granting a SQL Server login permissions to any of those objects. This became apparent when I was 100% unsucessful in testing the AspNetSqlProvider from the admin interface.

After spending an enormous amount of time working blind (SQL Server 2005 Express is only packaged with osql.exe, and no GUI tools such as Query Analyzer, SQL Profiler, or Enterprise Manager), I was able to crack the code. I ran the aspnet_regsql.exe as such:

C:\WINDOWS\Microsoft.NET\Framework\v2.0.40607>aspnet_regsql.exe -E -S (local) -A all -sqlexportonly aspnet_regsql.sql

This just created a script (and did not execute it against the server) for the local instance of SQL Server with support for all features. I looked at the roles that are created and realized that I needed to add at least myself (a local admin) to the most privileged user role. The reason why I knew this was because the admin website is running as a descrete app (not in IIS, but rather WebDev.WebServer.EXE), and it was running as me, according to the Task Manager. So, armed with this pearl of wisdom, I then executed the following against the ‘aspnetdb’ database in osql.exe.

1> use aspnetdb
2> sp_addrolemember N'aspnet_Membership_FullAccess', 'BUILTIN\Administrators'
3> GO

As I expected, when I tested the SQL Server Provider again, it worked. One big thing I learned here was how to drive SQL Server completely from a command line interface. So, at least I learned something.

I have just finished writing an Outlook 2003 addin for automating the process of uploading pictures and creating weblog entries. Once you have the addin installed, all you have to do is email a picture as an email attachment to an email address that starts with “modblog” (and of course have Outlook pickup this email). The addin then FTP’s the image to the server, and creates a weblog entry using the Blogger API.

I started a GotDotNet workspace for ModBlogger Addin. You can go and download the addin here. Also, there is a message board for asking questions, etc. My personal modblog is at here.

Ok, so I have been wrestling for the last few days with the fact that I was unable to debug .NET addins in Outlook. For whatever reason, Visual Studio would launch Outlook, and then it would crash almost immediately. I started to think that this might be a permissions issue. With that in mind, I broke out FileMon and RegMon from SysInternals.

RegMon turned up nothing, but FileMon did the trick. Just before Outlook crashed, it loaded v2.0.40301 (Whidbey) libraries, and what looked as if maybe even the Whidbey CLR. Anyhow, what I did was add an OUTLOOK.EXE.config file (yes, you can do that), with the following:

      <supportedRuntime version=”v1.1.4322″/>
      <supportedRuntime version=”v1.0.3705″/>

Well, sure as the sun rises in the East, it worked. By the way, the reason why I knew that this could be done was because I saw the runtime in FileMon look for this file, so I new the usual rules for config files applied even when the CLR is hosted in a non-managed application such as Outlook.

Oh the other thing that is the real problem is that I uninstalled the Whidbey preview, but it appears as if most, if not all, of the version 2 framework components are still there, and active none the less. I attempted to search Google for some idea on how to rid my system of verson 2, but to no avail. Anyway, as soon as XP SP2 goes RTM, I’m going to reinstall XP fresh.