I found out recently that Microsoft will be releasing source code for the .NET framework and libraries. There are some caveats, but we're all in agreeance: this is good news. Thanks, Developer Division, for opening up your code*!
Now, if you will allow me to turn my attentions toward the Office team.
If it's not already clear: the only thing we gained from the announcement yesterday is an official blessing from Microsoft saying "yes, it's okay if you look at our source code." We are already (allegedly) doing this unofficially and in an unsanctioned manner, today, with a little additional help from Lutz' Reflector. But in the distant tomorrow, with the release of Visual Studio 2008, we'll be bona fide. Bona fide!
It seems like such a small chasm we've crossed; such an easy step to take! Well, yes, but I haven't told you about Office yet.
In the beginning, it's always simple. In the beginning, I just needed to know why did my InfoPath forms break after I moved everything to a new server? In theory this should be a simple question. Yeah.
I've discussed elsewhere the problem of discoverability when working with SharePoint; this discoverability problem can be described by saying answers like this aren't easy enough to come by. It turns out, after this entire ordeal was over, I found this excellent page on the Office Center describing InfoPath migrations. Continuing:
After browsing Google, checking the Technet Forums and USENET, I (allegedly, Your Honor) decided to look into the source of this InfoPath Migration tool. If you don't know what the InfoPath Migration tool does, I'll quickly say that if you're moving InfoPath forms around, this tool makes the job a great deal easier. I'm thankful this tool exists, to be sure.
Anyway, because this tool was not working as I expected, I needed to be able to answer an entirely different simple question: does this InfoPath migration tool change the URN of each InfoPath form? I.e., if you have one form template and 1000 individual forms, does this tool update all 1000 individual forms, as well as the 1 template?
The answer I (allegedly, Your Honor) received from Lutz' Reflector is (allegedly) illustrated below:
So the question I pose is: what harm is it to you, Someone In the Office Division, to skip the extra step of obfuscating this tool? Just, you know, release it like 99% of everyone else is doing? (ok, ok, 99% is an exaggeration; a significant portion of vendors release their source code un-obfuscated, but additionally release in Debug mode, granting us richer decompilation information. Yes, you'd be surprised to find what is released in Debug mode)
Why not open this one tool up? No one's sharing any secret InfoPath sauce in this tool; this tool works on InfoPath's XML documents directly. Allegedly; I wouldn't know.
The Developer Division has promised to open up much of their code; why not open up some (or most!) of the SharePoint code?
Or, and this should be more reasonable to consider, take a different approach from today: instead of obfuscating everything, please consider instead why obfuscate at all? The idea is: please don't obfuscate by default.
Just say no! No to drugs, and no to obfuscation! And no to both drugs and obfuscation (an especially deadly combination)!
I was (allegedly) unable to decipher the raw, obfuscated IL inside of Reflector. So, defeated, instead of (allegedly) harvesting the answer directly from the source, I ran an experiment to find out what happens in this specific case.
I will point out that this is a terrible practice: combine two gargantuan, opaque frameworks, perform limited experiments on their interaction, and draw conclusions from any pattern that emerges. In science, they call this "testing a hypothesis", i.e. even if you get the desired result, they're not proven, and they can be disproved later. So having given a strong disclaimer, allow me to present the results.
After running the experiment, I concluded that InfoPath forms (specifically, the XML forms containing just the data) are 1) not modified by the InfoPath migration tool; instead, 2) InfoPath forms are modified during the "attach content database to MOSS web application" step of a WSSv2 -> MOSS migration. 3) Changes made to the web application's public URL afterwards did not affect the InfoPath forms (as it probably should have).
This is important to note, because if you're attaching your content database to a temporary (dummy) web application, then rename or otherwise move your web application's public URL, then guess what! Dead InfoPath forms**.
I'll make one last disclaimer: those three points above are not guaranteed to be true.
* Everyone should be generally pleased with this announcement. It's not a full-blown "do-whatever-just-don't-sue-us" MIT-style license, but it's closer now. There are about a hundred arguments for or against this, either way, and they're probably all already represented among the 700+ comments responding to the announcement itself. I'm just saying: at the very least, you have to admit this announcement seems to lack malice. Contrast this with the Office Ribbon license.
** Dead InfoPath forms means, dead until you fix it. It's just XML, and if you don't like to think in XML, then it's just text, and you can certainly do something programmatically either way. But as you learn with SharePoint, it's best if you leave these sorts of uncertainties alone and figure out what everyone else has already done in this case. And they aren't writing programs to manually manipulate every InfoPath form's data as if it were a text file, I'll tell you that much.
b, blockquote@cite, strong
© Copyright 2014, Peter Seale