Though work and family keep me pretty busy, everyone needs a hobby. Mine is online gaming. My current addiction of choice is City of Heroes where my favorite class to play is the Scrapper. Scrappers engage in close-range fighting with the enemy and are good at dishing out damage, which means they tend to go after the biggest bad-guys they can find in a group leaving others on the team to manage the lesser minions. Since this puts the scrapper in the middle of chaos with a limited scope of influence, scrappers often acquire what’s called "scrapper-lock"—they lose awareness of external contexts and miss important developments (like that their own health is in the red and it’d be a good time to pop a health inspiration).

This came to mind recently during a podcast on Dot Net Rocks. In this episode Carl and Richard talk with Udi Dahan about SOA. For all that Udi tends to discuss issues way above my scale enterprise-wise, I enjoy hearing him flog his hobby horse. He has the ability to make complex concepts understandable by using solid examples that relate well to his points.

Near the end of this episode (around 57:08), Carl asks "If there’s one big mistake that people tend to make, what is it?" Udi answers with our tendency to view challenges through the lens of our current obsessions and assumptions. His response reminded me strongly of scrapper-lock. It is really easy to look for solutions in terms of our current abilities and mind-sets. It is really difficult to take a step back and make sure you are taking on a problem in its entire context.

Stay on Target

There are two important factors to achieving IT goals. The first is identifying the target. This is actually the harder of the two factors because we bring so many unacknowledged assumptions to the task. The first assumption that messes us up is that we work for IT. We don’t. We work for companies, universities, governments, non-profit organizations, ad-hoc teams, and ourselves (and a multitude of other entities too varied to name). I tend to concentrate on corporate development so I’ll talk about working for a company below, but you can substitute any of the above just as easily.

In considering a goal, it is important to have not just a complete understanding of the goal itself, but of the reasons behind that goal. This is what makes software development such a challenge, by the way. You could train pretty much anyone to write the actual code. It’s learning to map the code to the needs of your company that causes real strain.

Take, for example, the requirement that you "hit a target roughly six inches in diameter from a distance of 150 feet." Which target did you see?

In this situation, you can ask all kinds of clarifying questions about the target (what color, outdoors or indoors, how much force etc) but the one question that is going to provide the best guidance is "why?"

Understanding the purpose gives you a load of related context that allows you to skip a lot of stupidity and identify buried assumptions. The reason this is so difficult is that in order to understand the purpose, you often have to understand the business (domain, university, non-profit et al) and most IT people resist doing so.

Gearing Up

Once you understand the target, deciding how you are going to reach it offers its own batch of problematic assumptions. Too often, we let our pet projects or obsessions intrude in this process. Are you creating a web interface because it’s cool and what you know or because it’s the best way to meet your business need? Are you implementing a new enterprise framework because the company needs it or because you really want to try out the whole SOA thing?

This is where integrity becomes important because you’ll often find that the best way to go is less interesting than the one you’d actually prefer. Every project requires trade-offs and those can leave you lots of room to nudge things in directions that might offer a slight advantage, but might also just scratch a personal itch to do things the "right" (i.e. your) way.

As the subject matter experts in our organizations, we have a lot of trust. It is easy to abuse that trust unintentionally by allowing ourselves to give too great a weight to our own interests (it’s also easy to abuse this trust intentionally, but that’s another post entirely). This tendency drives many of the fads you see sweeping through software development now and then (Extreme Programming anyone? Some good things are there, sure, but not nearly to the extent many of us convinced ourselves existed).

Acquiring a Strategic Overview

Because lock-in is so easy to fall into, it’s important that we develop some habits that overcome it. Here are some of my ideas, but please add or modify them in the comments if I’ve missed something useful.

• Develop some key general principles. It’s important that these be both "general" and "principles"—i.e. fundamental ideas that are valid regardless of programming environment or language. YAGNI is a good example of a general principle and one of my core tenets.
• At the beginning of any new project, make sure you ask the most important question: why? Further, make sure you understand the answer. It also helps if you take steps to understand your domain. If you program for businesses, for example, introductory courses in accounting and management are extremely useful. I use information from the one college accounting class I took way more often than information from my one college computer science class.
• Periodically review your tools. Is there a new kid in the Unit Testing world that might have some sweet capabilities (and an easy conversion utility)?  Has someone slain the dependency injection demon for Mock objects?
• Periodically review alternative environments. This is the hardest for me personally because I’m rather attached to MS Visual Studio and the .Net framework. Why should I bother with REST or Ruby or Eclipse? The important thing to learn here is perspective and the important perspective is not your own but that of the company (or whatever) that you work for. However comfortable you may be with Asp.Net, for example, it may be that your company can realize a substantial benefit by adopting Ruby. I’ll never forget the roadblock one developer on my team overcame in a day using python that I was afraid would set us back a week.
• Finally, make sure you are aware of and take the time to understand the current crop of buzzwords. Agile, SOA, TDD, Grid Computing, all of these have value or people wouldn’t be buzzing about them. It’s easy to become jaded after you’ve applied your third silver bullet and the slavering monster is still healthy and looking your way. Declaring all silver bullets useless and hibernating isn’t going to help you. When management comes to you with a new solution they read about in their trade magazine, you’ll get a lot farther if you can speak knowledgeably about its strengths and applicability in your environment. And who knows, you may just find something that slays one of your own dragons while you’re at it.

This rating was determined based on the presence of the following words:

• pain (7x)
• dead (1x)

Since this is a blog about technical topics in general and software development in particular, I suppose it makes sense to have the word "pain" crop up now and again...

There's a reason that my personal blog is named The Rabid Paladin—I form opinions easily and express them strongly, even as I attempt to maintain an even keel through my sense of integrity. What this means is that on those occasions when I enter an argument with the purpose of informing and/or convincing others, I try to remain open to valid points from other perspectives and the possibility that I might be wrong.

Letting Bias Show

Too often, people arguing their case will paint alternatives in as bad a light as possible—perhaps believing that their misrepresentations make their arguments stronger. The true effect is that it weakens their argument when it becomes clear that their biases have colored their analysis. Technologists are particularly ill-served by this tendency. Computers function logically so there's an expectation that those who are able to understand and manipulate computers will be similarly logical.

So it's often disheartening to me when I see blatant bias in developers and other technologists. Note, I'm not talking about people whose opinions differ from mine or who value some aspects differently and thus favor other technologies or solutions or approaches. I'm talking here about people who want things to be a certain way and let that desire cloud their judgement and rhetoric.

There are a couple of good examples of this at work in the comments to my post about Microsoft. I actually struggled about doing this in a full-blown post because I don't want to pick on people who took the time to post here. I want to encourage people leaving feedback and don't want to give the impression that I'm trolling my own blog for people to make fun of. That said, the bias against Microsoft is something that I've been thinking about a lot lately and this gives me an opportunity to illustrate things that I find off-putting.

Sloppy Equations and Florid Adjectives

The very first comment is by "LKM".

How about "they engaged in blatantly illegal business practices in order to destroy their competition"?
It's not like they were not found guilty of this by a US court.

Now, it's not clear if the reference is to Microsoft being a monopoly or the broader point of Microsoft being evil, but the terms used here clearly show a bias against Microsoft. First off, being found guilty of violating a U.S. law is hardly proof of being either evil or having a monopoly. Name one company Microsoft's size and age that hasn't been sued successfully.

The cold, hard, unfortunate fact of corporate life in the U.S. is that large companies make attractive targets for lawsuits from individuals, corporations, and government entities. Being ethical (or "not evil") isn't protection from being sued, nor is it a shield against conviction. The worst you can say about Microsoft from the fact that they were sued successfully is that they were sued successfully. Any further conclusions that you wish to draw from that conviction still have to be backed up by reason and logic.

Second, LKM's description of Microsoft's business practices as "blatantly" illegal is an example of an intensifier that ends up undermining instead of emphasizing. If their practices had been blatantly illegal, then the trial would have been extremely short if it had gotten to court at all. Microsoft didn't get to where they are today by being stupid about how they spend their money and there's nothing dumber than trying to defend the indefensible.

Frankly, describing Microsoft's actions as blatant also indicates LKM's opinion of those who don't agree. Used maliciously, framing it that way could be seen as a way to cut off debate by implying that you'd have to be blind to disagree. I'm not saying that LKM was deliberate in this or that it was intended as such. Still, this is a form of what I meant in the conclusion of my prior article when I say that painting Microsoft's users and/or supporters as stupid is not a useful way to convince them that you are right.

Ignorance and Hyperbole

Syd from Fairground Town is a little more articulate, but in the end comes off as much more biased.

For me, the incident which summed-up MS was Genuine Advantage. It wasn't the fact that they did it, which I guess was fair enough (what with it being their software 'n'all) but their spokesperson on BBC Radio telling us that "Customers have been crying out for a way to know if their copy of Windows is genuine." This was a breath-taking "big lie", worthy of Goebels, and it was the "last straw" that made me shut down my ten-year-old Hotmail account and buy a Mac.

The beginning here seems like Syd is going to be reasonable. It's a good first step to acknowledge that someone has the right to do something even if you (presumably) disagree with them doing it. He undermines this by displaying both ignorance and extreme hyperbole further in, though.

Now, I didn't hear the spokesperson in question so I can't properly contextualize the quote Syd offers, but I'm willing to bet that Syd doesn't work in a large IT department—a context where the spokesman might actually make sense. While it may be the case that BBC Radio failed to contextualize the quote he heard (making his initial ignorance not his fault), it's important for someone actually trying to be reasonable to look for how a statement that seems so ludicrous actually could be true. Few people lie deliberately or blatantly in a forum guaranteed to reach millions of people. Microsoft's spokesman had to have had a reason for this statement, even if you end up disagreeing with it. Understanding what that reason is should be the very first step in an incident you plan to describe as motivating some action on your part.

Personally, I have worked with a couple of companies where one of the largest headaches of the systems guys was tracking licenses so I understand where the spokesman could be coming from. Licensing was a particularly onerous task at XanGo because our growth was so extreme. The anti-piracy folks at the BSA have managed to win enough cases and levy heavy-enough fines that companies really don't want to go through the expense of an audit that finds that they are out of compliance. One aspect of Genuine Advantage includes the ability for sysadmins to track this automatically and I suspect this is what the Microsoft spokesperson was talking about.

But really, Syd loses me entirely with the Nazi reference. As we gain distance from the horrors of WWII, people seem to be increasingly willing to use Third Reich references to vilify people they disagree with. It makes me wonder if they know anything about the reality behind those events except as a way to put their opponents beyond the pale. It's an obnoxious rhetorical trick and one I've come to despise. I'm to the point any more where I automatically discount anyone making a comparison to anything Third Reich, even if I suspect I might agree with them. The strength of the hyperbole automatically disqualifies them as someone I'm willing to take seriously, let alone support. I mean, if you break it down, Syd is implying that a spokesman for Microsoft is on the same level as someone who covered for the wholesale slaughter of men, women and children.

This comparison is so extreme that it leads me to suspect not just Syd's sincerity but his veracity as well. I suspect he already owned a Mac and already intended to shut down his Hotmail account (assuming he had one). In fact, it's reminiscent of the rhetorical device where a commenter will claim an affiliation they don't have in order to lend weight to their statements (like someone describing themselves as a lifelong member of a political party even as they regurgitate the talking points of the opposition).

Passion, Conviction, and the Right to be Wrong

Now, I'm not saying that either commenter had no right to their opinion or passion. I'm too passionately opinionated myself for that to fly. What I'm saying is that having passionate opinions doesn't mean you should paint counter arguments as less than they are. Doing so diminishes all participants in a discussion, starting with yourself. Indeed, both Syd and LKM ended up undermining themselves to me more than they did Microsoft with their arguments.

I like to tell people that I maintain the right to be wrong. I know that I've been wrong in the past (with a stellar example on this blog just last week). I know that I'll be wrong in the future. Knowing this, I have very few convictions that aren't open to reasoned argument. But please note the modifier there. I don't think that I'm alone in being put off by argumentation that is long on passion and short on logic. Particularly when the terms of those arguments attempt to railroad me or use rhetorical trickery.

And I continue to believe that implying someone is blind, stupid, or allied with murderers is a poor way to convince them to take you or your arguments seriously.

UPDATE: Well suck. It turns out neither Martin nor Ayende deserve my censure here as NUnit uses the zlib license (which is extremely permissive). I managed to mix NAnt (which uses the GPL license) with NUnit. My bad. I hate when I mess up enough to invalidate my own points...

A number of bloggers take for given Microsoft's antagonism towards Open Source Software. Quotes like this from Martin Fowler are representative.

I was particularly sickened by Microsoft's reaction to NUnit - an excellent XUnit testing tool, elements of whose design were lauded by Anders Hejlsberg at OOPSLA. Microsoft ended not just bringing out a competitive library, but deliberately making it incompatible. That's not the kind of reaction that encourages people to invest their time in the platform.

Who Shot First?

The thing that these bloggers are overlooking is that Microsoft didn't open this licensing war. Open Source Software started this with the "CopyLeft" or "Viral Licensing" movements. These began with a set of licenses that deliberately forced anything a developer worked on that was "related" to the project to accept the same terms as that license. That meant that developers working on one of these projects could compromise the copyright of their employer if the projects could be construed as being similar. Special note about litigation: typing code instructions on a keyboard for the computer to interpret could have been construed to be "similar". The "Free" software movement thought this was a great idea and all but salivated at the opportunity to "liberate" corporate software.

That these same advocates were shocked, shocked I tell you, that companies like Microsoft then forbade their employees from working on Open Source Software even at home shows how disingenuous they can be. Again, the terms of some of these licenses were openly antagonistic to corporate-owned software and designed to jeopardize corporate software licenses. Unable to spend the resources to review every conceivable license all the projects their employees might work on, it's no surprise to me that a company will chose to go with a total ban on Open Source Software. Microsoft, in particular, is an attractive lawsuit target so it's no surprise that Microsoft was one of the first companies (if not the first) to ban its programmers from contributing to Open Source Software projects.

Things have calmed down a little from the initial hostility in the Open Source Software community as more and more devotees discover that they can't dictate terms to people with more resources than them. There are still nutballs on the fringe who maintain that Microsoft is simply evil and anyone who uses Microsoft technologies to develop applications is evil by association. While these strident voices are few, Open Source Software still has features that derive from these antagonistic forces.

The GNU General Public License

Robert Heinlein taught me that there ain't no such thing as a free lunch. I have found this assertion to be true.

Take, for example, the much vaunted GPL license. The GPL claims:

The GNU General Public License is intended to guarantee your freedom to share and change free software--to make sure the software is free for all its users.

Most people have no idea what the specific terms of the license are and are content to take the FSF's word that GPL == free. This is not the case—it is not designed to give you freedom to share and change software if you ever want to recover your costs of development.

Specifically, the GPL license is an irrevocable license that includes requirements for anything "derived" from a work covered by it. These requirements include that anything you try to improve in a GPL licensed project is automatically and forever a commercial dead end and that you are required to release your source code for your improvements. In other words, all resources spent on a GPL licensed project are guaranteed to be thrown down the rabbit hole. That's hardly "free" use of the software.

As if that weren't bad enough, GPL carries a notification requirement such that anything that runs based on GPLed (or derived) code must present the GPL license information "conspicuously". I shudder to think what would happen if Microsoft had to include a conspicuous GPL notification on every installation of Visual Studio. The confusion over what's covered and what isn't is enough to set lawyers circling like sharks around a sinking sushi tanker. Plus, it amounts to free advertising for an organization that is, at best, antagonistic to Microsoft's interests. It'd be like forcing developers to open Internet Explorer in order to start Firefox (or vice versa). Not. Going. To. Happen.

Microsoft vs. NUnit

NUnit uses the GPL license, so I take both Fowler and Ayende Rahien to task for either ignorance or disingenuousness when they claim it is Microsoft's fault that NUnit wasn't picked up to become Visual Studio's unit testing framework. If you want Open Source Software to be picked up and improved by large companies, then don't use licenses that are antagonistic to large companies. I don't see how that's so confusing or controversial.

In addition, a project that is as popular and widespread as NUnit that has a GPL license associated with it is a project that Microsoft not only won't be able to adopt, they also won't be able to release anything compatible with that project without opening themselves to all manner of unseemly accusation and lawsuits. It's an unfortunate fact of the real world today that a number of highly motivated people are out to sue Microsoft. In that kind of environment, Microsoft has to take steps to reduce their legal liability and this is one of those steps.

A Middle Ground

There is hope for the future. Many licenses are in wide-spread use today that don't have GPL's more onerous terms. I don't have a feel for which licenses are most popular, but if you sincerely want to see Open Source spread into corporate environments, like Microsoft's, I recommend taking a close look at the license you are using for Open Source projects. Creating licenses that aren't directly antagonistic to corporate interest is a good step in the right direction.

On the other hand, if you continue being hostile to corporate interests, don't act all surprised when your work isn't picked up by large corporations. Cause, meet effect...

First post exclusively on the new, IT-focused blog. Cool.

We've had a lot of turn-over at my current place of employ lately. We've lost most of the Operations team and all of the Accounting team in the last couple of months. It's not hard to see why: those departments are caustic and frustrating. In contemplating the turn-over, I realized that I really like working in IT.

It's not just the technology. I like working with the people in IT. Sure, we have our share of jerks and anti-social Neanderthals, but even they are at least interesting.

Maybe I've been able to call the shots for too long. For the most part, I've been able to be choosy with the places I work and who I work for. That means I've been able to avoid the obviously dysfunctional organizations, or, as with my time at XanGo, I was in a position where I could keep the dysfunctional from entering the departments I worked in.

The best part of working in IT, though, is being able to issue the challenge "Show me." when someone makes some claim that I find dubious. In the end, it all comes down to something measurable. Fads, snake oil, silver bullets, and grand new things happen all the time here (as they do anywhere) but eventually every one of them hits the brutal wall of reality. The way things are in IT, reality's pushback comes sooner than later.

Like many businesses, my current employer uses Microsoft Dynamics GP for our main  accounting/inventory software. From a recent trip to Connections (the big convention for Dynamics), I learned that there were some cool data mining utilities available from Microsoft that we might be able to use. I love free stuff, and the opportunity to give our executives something to chew on for a bit (keeping them out of my hair) was one I couldn't pass up.

The Analysis Services install I managed to dig up (after much searching on Microsoft's Customer Source) went pretty easily. There are a couple of SSIS jobs included that populate an summary database with relevant data pulled from the objects you want to throw into your data warehouse. Not too shabby, even if it's an extra aggregating step. In fact, I kind of appreciate the added encapsulation and I know I'll have to restrain myself from using this database for other reports.

Anyway, the only thing left at that point was to "process" the data warehouse. That's where the data warehouse reads the "factual" information and chunks it up into nice little cubes that should have precise business-person meaning. It can take a while, so I was prepared to leave the process running a bit.

Five hours later...

We're just not so big a company that this thing should have taken five+ hours. Digging into the process that was taking so long revealed that at least one of the dimensions it was trying to process included a table join that seemed a bit fishy. It included a master-detail relationship that should have ended up with something around 500,000 rows. Checking the "Estimated Execution Plan" on the generated select statement showed that it was estimated to return closer to 2 billion rows. That's a messed-up join is what that is.

Fortunately, Visual Studio 2005 gives you some cool tools that work with Analysis Services. One of them is a wizard that you can point at a data warehouse and have it reconstruct it as a project. Checking the Data Source View "GPDataWarehouse.dsv" revealed what the problem was. Roughly half the relations in that view had split the key so that there was one for the actual relation minus the CompanyId and another with the CompanyId all by its lonesome. The effect of this is that the data warehouse would process once for the real relationship and again for the spare. Since CompanyId is the same value for all my records, what I ended up with was a data set getting ready to relate 147,698 records with every one of 11,937 records. I'll spare you digging out a calculator; that's 1,763,071,026 rows total.

Now frankly, I could have simply removed the CompanyId entirely from all relationships—CompanyId is only really relevant if your Dynamics install is trying to manage multiple companies. We aren't doing that. Still, I can be a little, uh, rigid with stuff like that so I went ahead and changed the relevant relationships to include CompanyId and simply deleted the spares. Once I deployed the project back to the data warehouse, processing it completed in a mere 15 minutes.

I suspect that the cause of this disjointed relationship is that the original warehouse was configured for SQL Server 2000 and we're using SQL Server 2005. At any rate, things are a lot happier now. I have an SSIS package that kicks off the summary database update and then processes the cube and the whole thing runs at night in 20 minutes or so.

For those who might be experiencing similar issues, I've uploaded my working Data Source View. You should be able to replace yours using SQL Server Management Studio. I selected all the options on install so it includes the Financials, Inventory, Payables, Purchases, Receivables, and Sales cubes. I'd do a backup before attempting it, but you were probably going to do that anyway...

Have you ever hacked a product to do something it wasn't intended to do in order to "simplify" things for your users and have that blow up in your face? This is an account of my experiences doing just that with MS Reporting Services.

If you've used Reporting Services at all, you'll know that there are two virtual directories that are created on IIS when you first install it to a server: ReportServer actually serves up the reports by passing the requested data to external applications via whatever protocol you have configured and Reports (aka ReportManager) which serves as a user interface for reports on the server.

ReportManager is, by far, the most visible of the two. Using ReportManager, you can organize your reports and data sources and set permissions on who can view and change them. Often, this is enough of a user interface that it is a viable deployment mechanism to simply point your users to the Url for a report under the ReportManager directory.

Ingenious people, like myself, will often designate a new Web instance on IIS just for Reporting Services, generally naming it something clever like "reports". When you do this, it is very tempting to point the root directory of that web instance to the ReportManager directory. This means that you can point your users to "http://reports/Invoice" instead of "http://reports/Reports/Invoice". You can see why you'd want to make this change (assuming you are similarly obsessive).

There is, however, an unintended side-effect to this change. Once you do this, your ReportServer will begin throwing errors if you ever decide you want to use direct Url access to display reports. Not a lot of people do this unless they're using a Reporting Services "Integration" that uses this functionality for showing reports. Personally, I ran into this situation when trying to tie our Reporting Services forms into Great Plains. Since Great Plains integrations (both native and third party) expect to use ReportServer for the report display, I was shocked and dismayed to find myself staring at this error:

The type Microsoft.ReportingServices.UI.WebControlConnection, ReportingServicesWebUserInterface, Version=9.0.242.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91 does not implement IReportServerConnection or could not be found

Hitting Google for this error is more than a little bit frustrating because the vast majority of issues where it shows up is in mis-configuring a ReportViewer object in an ASP.Net web application. This is manifestly not the case here.

This was a dome-scratcher for a lot longer than I like to admit. All of the advice pieces that I could find for this error are simply inapplicable. Fortunately, I ran across a Usenet post by Dave Green from last July. Dave reported that he could fix ReportServer if he removed a couple of settings from the <appSettings> section of the ReportManager. This is most odd because the two simply shouldn't be linked--at least, in that direction. If they were linked, I'd expect that link to go the other way (i.e. something in ReportServer breaking ReportManager). After all, ReportManager is essentially a UI on top of ReportServer.

I tested his findings and sure enough, removing the appSettings fixed ReportServer for me. Since removing those settings broke ReportManager, this was an unappetizing solution.

It was then that I remembered that IIS does an interesting little trick with web.config files and subdirectories. You see, each subdirectory on a website inherits the configuration from parent directories (also machine.config, but that's not relevant to our story). It doesn't matter how those directories are physically arranged, what is important is that IIS uses the Url to determine inheritance. So in a situation where "http://reports" is pointing at ReportManager and "http://reports/ReportServer" is pointing to ReportServer, that means that ReportServer is inheriting the web.config settings from ReportManager. Thus, the appSettings for ReportManager are being read by ReportServer and misapplied (I've no idea why the presence of an appSettings entry would break ReportServer)

Fortunately, the fix for this issue is pretty simple. The <appSettings> element includes a spec for a clear directive that will wipe out all inherited values. Adding an appropriate entry to the web.config in ReportServer cleared the problem right up. Here's the section for the curious (and/or lazy):

<appSettings>
    <clear />
</appSettings>

So there you go. I hoisted myself by my own petard. Fortunately, I was able to figure out how to get myself unhoisted. I now have both ReportManager and ReportServer humming along nicely without having to undo my clever directory mapping. Since I haven't been able to find this solution anywhere, I figured I'd post this for those in similar situations.

The trend towards increasing security introduces a number of intricacies for medium-sized business software shops using Active Directory Domains. An internal domain with more than a dozen workstations can introduce issues that are old hat for larger shops, but way beyond anything a small business will have to deal with. I ran into one such issue recently when I decided it'd be a cool thing for one of my apps to actually run from the network.

The Problem

The first sign I had a problem was when a module that worked fine locally threw a "System.Security.SecurityException" when run from a network share. It told me that I had a problem at "System.Security.CodeAccessPermission.Demand()" when requesting "System.Security.Permissions.EnvironmentPermission". Since it worked fine while local, I figured I had a code trust problem and that I could probably get around it in the .Net Framework Configuration settings and push a domain policy that would update everyone.

I knew this because I had run into something similar once before (deploying a VSTO solution on the network).

Here's where it pays to be a real (i.e. lazy) developer: since I've run into this before, wouldn't it be nice to come up with a solution that will make it easier when I run into this in future? There are four ways to do this, I figure (well, that I could think of, there are probably more).

1. Create some kind of scripting solution for deploying future projects that automatically creates policies (and propagates them) for each new assembly.
2. Create a standard directory on the network that can be marked as "trusted" and deploy any trusted code into that directory.
3. Use a "developer" certificate as your trusted publisher.
4. Figure out how to get a publisher cert to use to sign your code and then propagate a rule certifying that publisher as trusted.

Some developers would go with number 1. Which makes me shudder. Anyone using the first option isn't someone I want to code with or after (barring some quirky deployment requirement that makes it more attractive, of course). Number 2 would probably be the most common solution because it's pretty simple and most medium-sized businesses are used to security compromises that use "special knowledge" and a lack of being an attractive target for security trade-offs. Number 3 would be a little more "upper-crust", mainly from people who had tried 4 and run into difficulties. And frankly, for most cases Number 3 is likely adequate. The problem is that using number 4 has a couple of not insignificant hurdles.

The Issues with Certificates

There are a couple of obstacles in your way if you want to produce a valid publisher certificate for use in signing code.

• For a smaller internal shop, going the "official" route of contacting one of the major certificate stores (Thawte, Verisign, et. al.) is overkill with a price tag.
• Setting up a private Certificate Authority isn't that hard, but unless you're running Windows 2003, Enterprise Edition, you cannot customize certificate templates.
• The settings on the Code Signing template marks the private key as "unexportable".

That last is the most significant problem. You see, if you cannot export your private key, you cannot export to a "pfx" file (aka "PKCS #12"). You could export a .cer file (public key only) and then convert that to an spc using cert2spc.exe but that leaves you with a file that pretty much anyone can use to sign code. There's a reason Visual Studio Help warns that cert2spc.exe is for testing only.

If I lost you in all the security acronyms, don't worry about it. The important thing to note is that a) non-pfx files don't need a password to use in signing assemblies and b) there's no easy way to create a non-developer created pfx file signed by your organization's CA.

How to Get Your CA to Issue an Exportable Certificate

There is, however, a loophole you can exploit to con your CA into giving you a Code Signing certificate that you can export into a valid .pfx file. I'll skip the setup stuff on the CA. It is important to make sure that your CA makes the Code Signing template available (it isn't by default). Making it available is pretty straightforward, so I won't go into that here.

The first thing you'll need to do is use makecert.exe to create both a private and public key. A basic commandline to do so would be:

makecert -n "CN=Text" -pe -b 12/01/2006 -e 12/01/2012 -sv c:\test.pvk c:\test.cer

You can hit the help file for other fields you might want to set (or use the -? and -! switches to get two lists of available options). This command will pop up a GUI prompt for your private key password. Note that I typoed "CN=Text". While I meant to make that "Test", it turns out to be a good way to illustrate what that value is so I decided to keep it in the following examples. Also note that "-pe" is what makes the private key exportable. After running this command, you'll have two files in your root directory. The pvk is the private key file and the .cer is the public key.

Next you use a Platform SDK tool called pvk2pfx.exe. This wasn't in my regular path so I had to do a search to find it. I'm guessing that most development machines will have it already. If not, it's available from Microsoft. Here's the command I needed:

"C:\Program Files\Microsoft SDKs\Windows\v6.0\Bin\pvk2pfx.exe" -pvk c:\test.pvk -spc c:\test.cer -pfx c:\test.pfx

Like makecert, this command will give you a password dialog for the private key. Note that even though the command switch is "spc", it'll accept a .cer file just fine. Now, you might think that we're done because we have a valid pfx file. The problem is that this pfx file is derived from a CA of "Root Agency". In order to get this into your internal CA, you're going to need to use your certificate manager. You'll likely need to Run certmgr.msc to get to it. Once there, head to the Personal|Certificates node. This will let you play with certificates on your current workstation.

Right-clicking on "Personal" gives you an "Import" option. Follow the prompts to pull your certificate in. It'll prompt you for the private key password. Once you do this, you'll see your new private key and probably an auto-imported "Root Agency".

Here's where we find the handy loophole. While the default value for allowing private key exporting on the Code Signing template is false, you can use your handy new certificate to request a duplicate. Right-click that key and select "Request Certificate with Same Key". You can also use "Renew Certificate with Same Key". The functional difference seems to me to be that Renew keeps your password while Request provides an empty one (which is nervous-making, but rectifiable using a number of different tools including Visual Studio once the certificate is exported).

In the Wizard that follows, make sure you select the Code Signing template. What you'll receive back is a certificate from your CA for code signing that includes a private key that is marked exportable. At this point, I delete both the "Root Agency" and "Text" certs in order to avoid future confusion.

Use the Right-click|Export command to export this certificate to a pfx file. The pfx file has everything you need to be able to create a .Net Framework code policy using "publisher" as the distinguishing characteristic to mark your code trusted. Once that policy is propagated to all the domain workstations, you're good to go. You'll need to use the resulting pfx file to sign the assemblies (once they're ready for release), but you knew that already :).

A Final Note

After I had a valid certificate for signing, I actually ended up using .Net's ClickOnce technology to deploy the project. I still needed a certificate to create a strong-named assembly, but a weaker or temp certificate would have been adequate for internal deployment. The more robust certificate will let me eliminate a security prompt the first time a user runs the application, though. Since that prompt has a big red exclamation point in it, I'm just as happy to eliminate it.