This is a random post, but I figure it might help someone, since I couldn’t figure out what was going on for the longest time.

I installed Visual Studio 2010 / .NET 4.0 Beta 2 last night. When I restarted my laptop, I noticed that both the Microsoft Online Services Sign-In app and the Curse-Gaming Client crashed. When I tried to start them manually, the same thing happened.

There were no errors in the Event viewer and no log files, so there was no obvious reasoning. Repairing the .NET 4.0 and .NET 3.5 SP1 installations didn’t fix anything either. The only clue I had was from trying to debug the crash in Visual Studio when prompted by Windows. Even then, the error was still cryptic: The type initializer for 'MS.Win32.Penimc.UnsafeNativeMethods' threw an exception.

Several Google searches later, I found the following fix:

1. Run Command Prompt as Administrator.
2. cd \windows\microsoft.net\framework\v3.0\wpf
3. regsvr32 PenIMC.dll
4. cd \windows\microsoft.net\framework\v4.0.21006\wpf
5. regsvr32 PenIMC.dll

Once that was done, I was able to run both applications without error.

I’m proud to announce that today IncaBlocks, FuncWorks‘ first game, released on the Xbox Live Indie Games marketplace. It’s a block-stacking family board game for 1-4 players.

This represents a few months’ work on the part of Mike, Cicelie, and myself (you can read more over on Mike’s blog), and it’s exciting that it’s finally paid off. It’s amazing to think that code I wrote is not only running on a real game console, it’s being sold on Microsoft’s online service.

So if you have a 360, please check it out. There’s a free trial available, and the full game is just 80 points ($1). And if you like it, rating it would be much appreciated!

While my job focuses on ASP.NET development, I still find myself going back to Python and SnakeSkin for personal web development projects. There’s really two reasons for this. One, I’ve got a pretty nice Linux virtual server hosting account through OpenHosting, so hosting on Apache gives me a lot of freedom. Two, I like the fact that it’s a bit lower-level than ASP.NET (so I’m a little closer to the HTML code) and not as opinionated as an MVC framework like Rails or CakePHP. Three, real men code in vi from the command line.

One of the great strengths of SnakeSkin/Albatross is its handling of form and session state. It’s roughly equivalent to ASP.NET’s ViewState. However, this makes AJAX work a little tricky. When a form is submitted, the posted fields are validated against the original structure of the form on the page; if they don’t match, SnakeSkin throws an exception. Great for keeping spammers out of your contact forms–but not so hot for changing page structure on the fly. And for years, I’ve sort of had to deal with this limitation. Usually, my workaround was to use a separate controller that returned XML data, which I then used to update the page through JavaScript. Fine for small things (and certainly less bandwidth-intensive), but not convenient.

I could go into the complexity of the problem even more, but it boils down to this: you can’t easily update one portion of the page directly. It’s all-or-nothing.

I eventually hit upon half of the solution to the problem a few months ago. If I updated an entire <form> tag in its entirety using prototype’s Ajax.Updater, then the form data would remain intact, and wouldn’t break when I submitted it again. But this was a very limiting solution. If you used multiple <form> tags on a page, then their session state (stored in hidden fields) would get out of sync as you updated each one individually. So, the only way to really make this solution work was to include only one <form> tag on the page. And if you’re doing that, you might as well not use AJAX at all.

It took some time, but the solution finally hit me. It was during Wally McClure‘s ASP.NET AJAX presentation at ETNUG. I had a pretty good idea of what was going on behind the scenes with ASP.NET AJAX, but I’d never really thought about it too much up to that point–the details were safely hidden from me in the Microsoft library, so there was no point in delving into the complexity.

But part of Wally’s presentation was to open up Fiddler and show the actual text of an ASP.NET AJAX response. The response contained the HTML code to be inserted into each UpdatePanel–which was pretty much what I expected. But it also included the updated ViewState as a separate field in the response. And that’s when it clicked.

All I had to do was modify SnakeSkin to spit out both the session state and the HTML response as part of an AJAX call. Then, when the response came in, I would iterate through the <input> tags on the page, and replace the contents of each hidden session state field. This didn’t require a lot of work on the back end (surprisingly, as I’d imagined the code to generate session state was hidden deep within the bowels of SnakeSkin), and only some minor tweaks on the front-end code I’d been using for AJAX.

So, last night, I actually got two-panel demo working. It’s obviously nowhere near as complicated as ASP.NET AJAX’s UpdatePanel–modifying my SnakeSkin page class to support updating multiple sections of the page in one call would just overcomplicate it at this point. But it is a somewhat elegant solution to the problem–that is to say, it’s encapsulated enough that the details of “how” are nearly invisible when you’re creating a page class.

I’ll post some samples if anyone’s interested, but SnakeSkin (and probably Albatross, the project it forked) is so obscure this doesn’t really matter to anyone but me.

The point is, I found it interesting that I solved a problem in one framework just by looking at another. I didn’t copy the solution directly, but it gave me a new way of looking at the problem. So, while you shouldn’t learn every framework, language, and platform out there, it helps to know more than one.

This is especially true in web development, because in a sense, web frameworks don’t matter. Every web application–every HTML-based application that is, since Flash and Silverlight aren’t constrained by the same limitations–is basically working with the same set of inputs, outputs, and limitations. From the user’s perspective, what you can do with one, you can do with any other framework, whether you’re using PHP or ASP.NET or Rails or SnakeSkin or Perl. Obviously, that doesn’t mean they’re all equally suited to every task. The value in the framework is on the back end–maintainability, productivity, data, and support. So as different as they are, all web frameworks can’t be that different in their fundamentals, which means it’s easier to compare, contrast, and borrow concepts in the web arena than it is on the desktop or server.

I ran across an article today on SharePoint Magazine about Leveraging the SharePoint Platform. Overall, it’s a good (and realistic) discussion of how a SharePoint deployment must be planned supported within a company.

The section on people really stood out, because this was a point I made in my SharePoint presentation–if your deployment grows to any decent size, you can’t have just one person doing everything. Number of man-hours aside, it’s not reasonable for a single person to do configuration, administration, organization, development, and training. You’re trying to jump between a number of very different skillsets, so no matter how smart and capable your all-in-one SharePoint guy is, it’s not going to come out very good.

The article links to blog posts by Becky Isserman and Eric Harlan that attempt to define these roles a little more clearly. And for that reason, I think it’s a good read for anyone just getting started in a company that’s adopting SharePoint. Even if you won’t have a team of 4-6 people working on your SharePoint installation (and let’s face it, most people won’t), the division of skills is useful to divide up responsibilities between the team you do have–whatever size it is.

Here’s a problem one of the other developers here ran into–if you create your own site pages in SharePoint, you’re bound to see an error like this pop up:

An error occurred during the processing of /mypage.aspx. Code blocks are not allowed in this file.

… wait, what?

Yup, that’s what it says. You can’t use code blocks in ASPX files that are stored in SharePoint. No <% Response.Write("Hello World!") %>. No <%# Eval("Name") %>. As an added bonus, <asp:Button runat="server" ID="MyButton" OnClick="MyButton_Click" /> doesn’t even work because it declares an event handler.

That’s not really the gotcha here. This is well-documented in Inside Microsoft Windows SharePoint Services 3.0: check page 81, if you’re following along in your books at home. SharePoint has a very good reason for this security setting to be there: users can create and modify ASPX files that are stored within the SharePoint database. So, if you could run arbitrary code within an ASPX file, a user with no access to the server could potentially run malicious code.

So where does that code go? Well, it goes in the *.cs or *.vb code-behind file. That means to declare an event handler, you’re going to have to do something like this:

protected override void CreateChildControls()
{
    base.CreateChildControls();
    SaveButton.Click += SaveButton_Click;
    CancelButton.Click += CancelButton_Click;
}

And rather than displaying data in a GridView or Repeater using Eval() or Bind(), you have to give it an OnRowDataBound or OnItemDataBound handler. So that means, rather than doing this:

<asp:Repeater runat="server" ID="MyRepeater">
    <ItemTemplate>
        <asp:Literal runat="server" Text='<%# Eval("Name") %>' />
    </ItemTemplate>
</asp:Repeater>

You do this:

protected void MyRepeater_ItemDataBound(object sender, RepeaterItemEventArgs e)
{
    // Make sure we have a data item in this row
    if (e.Item.DataItem == null) { return; }

    // Convert the data item to its original type
    DataRowView dr = (DataRowView)e.Item.DataItem;

    // Find our literal control in the current repeater item
    Literal NameLiteral = e.Item.FindControl("NameLiteral") as Literal;

    // If it was found, set its value
    if (NameLiteral != null) { NameLiteral.Text = dr["Name"].ToString(); }
}

I can imagine you’re griping already. It’s easy to see the security reason for doing this–you don’t want users to be able to run arbitrary code on your server. But it’s so freaking complicated. (Well, it is until you get used to the idea.) But as I said, that’s not the real gotcha here. So what is the point of this post?

The real gotcha here is that this doesn’t seem to be a default security setting, at least in the development environments we’re using. (Andy’s using a VirtualPC image he set up himself; I’m using Microsoft’s WSS3 VirtualPC image.) We only ran into this issue after he tried to install a project on the client’s server.

I don’t think we’ve figured out exactly what turns on this security setting in SharePoint configuration, but I have found out how you can force your development environment to throw these sort of errors. All you have to do is dig into your development site’s web.config file and add the following node:

<configuration>
    <SharePoint>
        <SafeMode>
            <PageParserPaths>
                <PageParserPath VirtualPath="/*" CompilationMode="Always" AllowServerSideScript="false" IncludeSubFolders="true" />
            </PageParserPaths>
        </SafeMode>
    </SharePoint>
</configuration>

Once that’s done, you can now catch yourself using stuff that’s not allowed in ASPX pages before it gets to your client’s server.

OK, Mike just tagged me with this meme, so here we go:

How old were you when you started programming?

I was in 5th grade. (I don’t remember my age at the time, but if someone’s really interested, I can do the math.) I started out by typing in programs from 3-2-1 Contact magazine’s “BASIC Training” column into QBasic. QBasic has a pretty good help feature, so I just moved on from there. Oddly enough, my main drive was to learn how to program video games, which (obviously) never really happened.

What was your first language?

QBasic. I later ended up picking up another BASIC variation called ASIC (because you could compile it), and then Visual Basic 4 from there.

After several failed attempts to pick up other languages (Java, and basically whatever free compilers I could get my hands on), I got into web programming with Perl. From there I went to PHP, then Python (after I took a job with Mediapulse), and finally C#.

What was the first real program you wrote?

I can’t remember. I had a couple of little DOS games that I did in QBasic and ASIC that were pretty polished (relatively speaking).

In 8th grade, a friend and I created a customizable quiz program for a school project and we tried to sell that. It was in ASIC 1.0, which kind of sucked compared to QBasic. Didn’t sell a single copy, but I eventually wrote a more polished version with mouse support and color after ASIC 5.0 released.

If you knew then what you know now, would you have started programming?

Definitely. And I would have had a better idea of what the next step was after BASIC. (Hint: it wasn’t picking up a “Java by Example” book and trying to write graphical browser-based applets.)

Whether I would have made it my career, that’s a different story. Likely so, but I might not have felt as sure that it was what I needed to do. (More on that in the next item.)

If there is one thing you learned along the way that you would tell new developers, what would it be?

Software development is a business, just like any other. New developers tend to think they can solve all the world’s problems–simplifying and automating business processes, creating applications to manage data that’s currently sprawled across several Excel spreadsheets, and things like that. I know; I’ve been there. The reality is, things are like they are not because no one’s ever offered to box them up in a pretty little application. The problem is they’re either very complex problems, or they’re simple, but people don’t take the time and effort to streamline and fix them. And if you want to fix the problem, you’ll have to understand why it’s like that in the first place, or you’ll just be adding to it.

You will have to learn a little bit of business analysis. You will have to deal with people climbing the corporate ladder. It sucks, but just because you’re an IT geek doesn’t mean you get to live in a world full of nothing but code and idealism. You’ll be able to accomplish a lot more good if you prepare for this–just don’t get sucked into it.

What’s the most fun you’ve ever had … programming?

When I was at Mediapulse, they pulled me off of contract work to work on a product called DealStream. Basically, it was a web application that would let funds handle applications for funding. They pulled me in after doing all the high-level planning, so I got to refine the application process and figure out how it translated to a web application. Then I got to code it, and had a lot more leeway to do it right (since it was a product we’d be maintaining and reselling) and make it really customizable. I built the database, then created a Python module to handle the data and process (using a ORM library I’d written), tested the crap out of it (not actual unit tests, but I did step through every possible path in the process), and then built the web application. The great thing was, we’d been working with MySQL, Python, and Apache so long that we really knew our stuff, and so I streamlined deployment and configuration quite a bit.

I worked with our first client to refine it into something that met their needs. Once the first site launched, I took versioning very seriously, since every client had to have their own copy of the software deployed to our web server, and I wanted to avoid branching as much as possible for maintenance reasons. (It’s not a product if every instance of the software is a customized version.) I even started writing a full documentation of the object model.

It was one of those projects that I put a lot of effort into, and just turned out great. (Well, from my perspective; I’m not sure how well it actually sold after I left.) Every time I write JavaScript, I wish I had a copy of the code. I had some really sweet text validation and formatting functions in there.

Who am I calling out?

Since I’m not sure who reads my blog regularly, and Mike has called out most of the usual suspects, let’s go with…

• Gabriel Cooper
• … and anyone else that feels like it.

As I mentioned in my previous post, WSPBuilder is a great tool for SharePoint development. Between its built-in commands and its project templates, it takes a lot of the hassle out of setting up SharePoint configuration files for your features and solutions.

However, it’s a little tricky to get it working for workflows, especially if you’re using Windows SharePoint Services instead of MOSS. Here’s what I eventually worked out:

• Make sure you’re using the “WSPBuilder Project with Workflow” template for your project. I made this mistake this first time through, and nothing worked.
• Remove references to Microsoft.Office.* Pull out the “ReceiverClass” and “ReceiverAssembly” references in feature.xml; you don’t need them anyway for a basic workflow. (If you do, you can always add them in later.)
• Remove the AssociationUrl, InstantiationUrl, and ModificationUrl attributes from elements.xml. You’ll need to add them back in if you create forms for this workflow, but not for a basic workflow.

In a previous post I discussed some of the trials and tribulations I’ve encountered with the mandate that we replace our current document management system with SharePoint. From the comments on that post, it sounds like pretty much everyone hates SharePoint to some extent.

Now, users, tend to hate anything that requires that they follow procedure or document their work, so it’s not entirely SharePoint’s fault. But some of it might be that SharePoint is being used for things it shouldn’t be used for. It’s a tool, and just like any other tool, it’s only good for certain situations. And even more to the point, it seems to have certain economies of scale as far as productivity goes.

I ran into a very simple problem today that, unfortunately, had a somewhat complex solution. A user’s Active Directory login name had changed, and I needed to update his record in a web application which uses Membership to handle its logins.

Now, of course, the easiest way to uniquely identify your users is by username. You can easily get the ID of the currently logged in user from User.Identity.Name. Of course, as I discovered, this is a Bad Idea, because now I have to update 14 fields in 11 tables.

Instead, it’s best to user the ProviderUserKey property of the MembershipUser. This means it takes one extra step to get the current user’s ID: Membership.GetUser(User.Identity.Name).ProviderUserKey

On the other hand, you can pass the ProviderUserKey value into Membership.GetUser just like you did the username.

Here’s a quirk I’ve been stuck on for a while in the process of rewriting this site in ASP.Net, and just recently figured out a workaround for.

When you’re doing any sort of URL rewriting with Context.RewritePath, all of your pages post back to their actual URL instead of the URL that the user requested. While this is fine if you’re simply redirecting because you changed the name of a file, it’s not so nice if you’re actually using this as the basis for your content management system. Which I do.

First off, if you’re doing any sort of URL rewriting, check ScottGu’s blog post on the subject–pay particular attention to the “Handling ASP.Net Postbacks with URL Rewriting.” This will clear up most problems you have with forms on your pages.

There are, however, a few quirks with the Login and LoginStatus controls (used with ASP.Net 2.0’s built-in membership system) that this won’t fix.

To make a functional login button, capture the original URL before rewriting, and then set the Login control’s DestinationPageUrl property to the originally requested URL.

To make a functional logout button, capture the original URL before rewriting. Set the LoginStatus’ LogoutAction property to Redirect, and the LogoutPageUrl property to the original URL.

Here’s an example of how I did it:

if (!Context.User.Identity.IsAuthenticated)
{
    ((Login)LoginView1.FindControl("LoginForm1")).DestinationPageUrl = originalUrl;
    ((LinkButton)LoginView1.FindControl("LoginForm1").FindControl("LoginButton")).PostBackUrl = originalUrl;
}
else
{
    ((LoginStatus)LoginView1.FindControl("LoginStatus1")).LogoutPageUrl = originalUrl;
}