Yes, it's 2008 and MOSS 2007 has been out for some time, but some of us are still flailing along with SharePoint 2003.  One gripe I have with SharePoint 2003 (among many), is the limited range of text markup you can do in a standard List--I guess this is largely due to the text editor control in SP2003.

One thing I would really like to do is create nice hyperlink text in the bodies of my list items.  Since the text editor control contains no feature to do this, I'm forced to literally paste hyperlinks into the body of my text.  This makes my posts less than attractive, but seems to be the only way to do it...until now.

The "Hack"

So, what I'd like to do is add a new item to, say, my Announcements list that looks like this:

Hey, everybody.  Be sure to check out Scott Guthrie's new list of .NET links.  There's some cool stuff there!

Notice that "list" is an anchor to the link I'm announcing.  Instead of that nice, tidy post, I have to do something like this:

Hey, everybody.  Be sure to check out Scott Guthrie's new list (http://weblogs.asp.net/scottgu/archive/2008/11/06/nov-6th-links-asp-net-asp-net-ajax-jquery-asp-net-mvc-silverlight-and-wpf.aspx) of .NET links.  There's some cool stuff there!

Here, I have to literally paste the link into the text of my post.  That might be fine for one or two links, but if I have several links to drop into my text, the text can become quite hard to read.  Well, recently, I stumbled upon a solution to my problem.

Step 1
In the text editor, just type up the text how I'd like it to look...



Step 2
Now, copy the ScottGu link in my clipboard and replace the word "list" with the ScottGu hyperlink...



Step 3
Now, very carefully, highlight the entire URL and type your link word over it: in this case, type the word "list" over it.  Notice that "list" takes on the appearance of a hyperlink!



Step 4
Save your post.  Now, you have nice, clean text in your list item and the hyperlink is still there, too!



The only problem I've found with this approach is if you wish to make your hyperlink text a phrase instead of a single word.  For example:

Hey, everybody.  Be sure to check out Scott Guthrie's new list of .NET links.  There's some cool stuff there!

In the SharePoint text editor, as soon as you hit that space between "new" and "list", the link seems to stop; thus, only "new" would become hypertext while "list" would remain plain, ordinary text.  If you must make an entire phrase a hyperlink, I guess you could either put an underscore (_) between words instead of a space or go through the trouble of repeating Steps 1-4 for every word in the phrase.  That might drive you crazy, but at least you'd have nice text!

 

Let's just call this Part 1 in a potentially lengthy series of frustrations suggestions aimed at Microsoft.  

To be clear, I like Microsoft: I make my living using Microsoft tools.  However, as with all things, I occasionally encounter frustrations with their tools and/or services and need a place to vent.  Well, here it is.

Suggestion: Please decouple the different tools within Visual Studio
One huge frustration for me is the apparent assumption that most/all Microsoft customers use the full stack of Microsoft tools.  I see this theme manifest itself in many different areas of software development, but for this post, I just want to focus on the tools for building, testing, and deploying .NET applications (mainly web applications).

So, here's my caveman view of the software development lifecycle (absent project management methodology jargon and concepts like iterative development):



In my diagram, I've identified different activities and where they occur: for instance, coding and authoring of unit tests take place on the developer's workstation while I expect formal builds, formal unit testing and analysis and even formal packaging operations to occur on the build server.  Finally, I've added suggested tools that are used for each activity.

Now let's talk about my frustrations: thanks to the tight coupling of the different tools within the umbrella of Visual Studio, we have to be very careful about what tools we use in development because those tools may not be available to build/test/package our code on the build server.  Unlike other shops, my company has quite a mixture of technologies in the software development stack--most important, this means no Team Foundation Server.  Note: I've observed most of these frustrations under Visual Studio 2005, but I'm not optimistic that they've been remedied under Visual Studio 2008.

My first problem is with unit testing.  When Visual Studio 2005 rolled out, my inclination was to run with MSTest.  That is, until I realized that MSTest required an instance of Visual Studio be installed on the build server.  Others have railed against MSTest in general, but my most immediate problem with it is the fact that I would have to corrupt my formal build environment with a developer tool.  It seems to me that having a development tool on the build server would be a violation of the separation of duties we try to practice at my organization, not to mention the silliness of having to buy an extra Visual Studio license just so it can sit on a build server and facilitate unit testing.  Frustration #1: MSTest cannot stand alone from the Visual Studio IDE.

So, let's scrap MSTest like Jeff Palermo did and go with one of the open source testing frameworks like NUnit (maybe, some day, Microsoft will decouple MSTest from Visual Studio).  That's great, but how do I calculate code coverage?  Visual Studio Team System will calculate code coverage but I assume that only works against tests written on the MSTest framework.  If I don't go MSTest, I guess that means I'll have to scrape together a few bucks (albeit not that much) and buy something like NCover.  Frustration #2: VSTS Code Coverage only works with MSTest (this is an assumption, to be sure, so if I'm wrong here, someone please let me know--and let me know how to configure VSTS to calculate code coverage on NUnit tests).

Alright: let's assume we've moved past the unit testing and code coverage issues.  We've made all the right decisions so that our code is going through formal builds and unit tests on a nice, clean build server.  Now, how do we push out our compiled artifacts to our Production server?  I get the impression that most folks at Microsoft advocate either XCopy or Visual Studio Publish.  These tools either require the Visual Studio IDE outright or a deeper knowledge of Microsoft deployment tools than the average deployment lackey will have (remember, separation of duties means that developers won't be the individuals deploying applications to Production servers).  

Personally, I'm a fan of deploying via Windows Installer files--that is, an MSI or installation EXE.  What's more, Visual Studio includes Setup project templates that make it easy for a developer to author the script that installs his product on the Production server--after all, who better knows how an application should be installed on a server than the developer himself?  

So, on my clean build machine, I have MSBuild or, perhaps, Nant compile my source code, run my unit tests, and maybe even do some code analysis.  Once that's all done, I have MSBuild use the instructions of my Setup project to build my MSI and...er, that didn't work?  You mean to tell me that MSBuild can't build my Setup project?!  Well, that's just nice.  And what's Microsoft's suggestion: use devenv.exe.  Yes, once again, sully my formal build environment with the Visual Studio IDE.  Frustration #3: MSBuild can't build my MSI.  

So, now, I either have to scrape together more dollars for a commercial product like Wise or InstallShield or learn to grapple with Windows Installer Xml (there do appear to be some MSBuild tasks for building WiX artifacts, though).

Confound it, Microsoft!  You have great tools, but your build and deploy story is a Grimms fairy tale!  Ok.  I feel a little better (not really).  If I'm totally off track here or if you have any better suggestions, please let me know.

Pretty descriptive error code, eh?  Well, I was going to put together an example of what aspnet_merge.exe can do, so the first thing I wanted to do was grab an example application, particularly one that makes use app_code files.  I decided to use the code from BlogEngine.NET.

Yes...I know, I know...the BlogEngine.NET code was never designed to live under a WAP-type model, but surely it can live under that model, right?  Well, uh, not without difficulty.

Step 1: Run aspnet_merge and see what happens
So, I used the Visual Studio 2005 Web Deployment Projects to construct a WDPROJ--an MSBuild project with sweet tasks to run the aspnet_merge utility.  (Note: as far as I can tell, BlogEngine.NET is still a Visual Studio 2005 solution)

At the command line, I typed: msbuild BlogEngine.web_deploy.wdproj



The build started and 54 seconds later...blam!  error MSB6006: "aspnet_merge.exe" exited with code 1.

So, what happened?  Sounds like this error happens when class names collide.  Like so many things, the Web Site project tends to let you get away with bad coding practices like using the same class name for a page's code behind in multiple places--so long as the pages are in separate folders.  Aspnet_compiler will compile separate DLLs so there's never the chance that a single assembly will contain two classes of the same name; however, when aspnet_merge tries to merge all the assemblies into one, the class names will clashes and cryptic errors like "error code 1" will get thrown.

Step 2: Figure out where my problems are and fix them
Unfortunately, the default console logging behavior of MSBuild does not tell me where my errors are, so, after consulting with my handy-dandy MSBuild command line reference, I figure I can do something like this to get more detail on where my errors are occuring:

msbuild /nologo /v:diag BlogEngine.web_deploy.wdproj > msbuild.log

Scrolling up from the bottom of my log, I see this error:

An error occurred when merging assemblies: ILMerge.Merge: ERROR!!: Duplicate type 'widgets_LinkList_edit' found in assembly 'App_Web_nbdnprem'.

Ah-ha!  Multiple classes each named widgets_LinkList_edit.  A quick search for that name reveals that, yes, that class name is used for both the edit.ascx code behind of the LinkList and TextBox widgets.  To fix, I'll go to the TextBox's edit.ascx.cs file and change that class name to widgets_TextBox_edit and to the page declaration in the associated ASCX page and update that, as well.

1...2...3...4 error code 1 issues later and it looks like I have a build!  But do I have a good build?

Step 3: Fire up my BE build to see if it works
Seems like the easiest thing to do is to fire up an instance of the ASP.NET Development Server to host my BE build, so I execute this at the command line:

WebDev.WebServer.EXE /port:8080 /path:"D:\MyTests\BE_Test1\BlogEngine.Web_deploy\Debug_test1" /vpath:"/BE_Test1"

And I get...a Parse Error:



It looks like the page is barfing when it tries to load the PostCalendar user control.  Interestingly, the PostList user control loads fine.  I wonder why?

Looking at the default.aspx markup code, I see that the PostList user control is registered at the top of the page, but the Calendar user control is not.  What gives?



Well, it looks like, as Phil Haack once explained, the controls with the "blog" prefix are registered in the web.config.  Didn't know you could do that.  Pretty cool.

<pages enableSessionState="false" enableViewStateMac="true" enableEventValidation="true">
<controls>
<add namespace="Controls" tagPrefix="blog"/>
</controls>
</pages>

This doesn't fix my problem, though.  ASP.NET Parse Errors are usually an indication that the CLR can't find the referenced class in the assembly.  Well, I know the PostCalendar class is in my single assembly (.NET Reflector told me that), so maybe the CLR is not able to find the assembly itself.  Maybe I can help.  Let's modify the control registration in the web.config with the assembly attribute:

<pages enableSessionState="false" enableViewStateMac="true" enableEventValidation="true">
<controls>
<add namespace="Controls" tagPrefix="blog" assembly="BlogEngine.Web_deploy"/>
</controls>
</pages>

Hey, what do you know?  It worked!  Now, the page loads up just fine.  Note that this last change I made in the web.config in my build folder; if you try to change the original web.config and then run BE from the IDE, you'll get a compiler error.  It seems to me that these kinds of issues can introduce a lot of challenges to development, as you try to account for the fact that the web.config you deploy to a Production server will need to look slightly different than the web.config that you run in your IDE.  I wonder if there are any MSBuild tasks designed to modify the web.config spit out by the build engine?  Scott Guthrie has talked about other important changes that should occur in your web.config before deploying it to Production.  I wonder if anyone has written a MSBuild task to accommodate those changes?

Clicking around in my pre-compiled BE instance, everything seems to work fine; however, I did encounter one show-stopping error that prevents me from doing important administration tasks--like adding a new entry.  At least I know that issue's related to the BE distribution I downloaded, not my build experiment with aspnet_merge.

So, what have I learned?  Doing pre-compilation on complicated Web Site projects can be tricky business--particularly when using aspnet_merge.  I wonder if I should just demo how to migrate a Web Site project to a Web Application project?

 

 

My company maintains different environments--Dev, IT, UAT, Production, and Disaster Recovery--in which to run and test software solutions: particularly web solutions.  My company also (I think rightly so) places restrictions on what environments developers can access and which ones they can't--the old Segregation of Duties principle.  So, the question is, how do developers build applications mallable enough to run under different environments that can be deployed as simply as possible so as to not confuse the server admins and deployment personnel?

Our deployment vehicle of choice is the old Microsoft Installer file (MSI).  With regard to environment-sensitive settings, we simply "extend" applicable sections of the web.config to a second environ.config file.  There are always edge cases, but this approach seems to work out pretty well on the whole.  The following is an example...

Step 1: Abstract whatever environment settings to a separate file.  In this example, I use the appSettings section to house my configuration values, but this pattern works for most other sections I've tried (eg. connectionStrings)

In my web.config

<appSettings file="environ.config">
<add key="key1" value="someOtherValue"/>
</appSettings>

In my environ.config

<appSettings>
<add key="MyEnviron" value="Development"/>
</appSettings>

 

Interestingly, the appSettings node seems to be the only node that supports the "file" attribute.  All other configuration sections I've extended use the attribute "configSource".  I noticed the other day, though, that appSettings also seems to support the "configSource" attribute.  It looks like you need to be careful about your use of that attribute, though (see the Note in the description of the "file" attribute).

Step 2: Create other environment configuration files for the different environments you need to address.  In my example, I've created a IT.environ.config, UAT.environ.config, and Prod.environ.config.  Each configuration should look the same--only the values should change.


Step 3: Test your app to make sure it works in your "Development" environment with your default environ.config file.

Step 4: Now, add a web setup project to your solution to package/deploy your solution.  For simplicity, I've used Scott Guthrie's Web Application Project so I can easily add the Primary Output and Content Files to my web setup project.  On the Content Files output, make sure to add the ExcludeFilter: *environ.config.  This will exclude our environment specific config files--we'll add them in later.

 

Step 5: At some point, someone has to know/decide what environment your web app is being deployed into.  I contend that that decision should be made at the point of deployment.  That decision can be fairly easily automated (and I'll probably talk about that in a future post), but for now, we'll place that decision in the hands of the human installing your MSI on a given server.  

1. In Solution Explorer, right-click on your web setup project and select View > User Interface from the context menu.
2. In the User Interface tab, right-click on the Start node and select Add Dialog from the context menu.
3. In the Add Dialog dialog, select the RadioButtons (4 Buttons) choice and click OK
4. Move your new dialog to the appropriate order (usually after the Welcome dialog)
5. Set the properties of the dialog more or less as follows:

 

Step 6: Go back to the File System tab.  Under the Web Application Folder, one by one, add each of your environment config files.  For each file you will need to set two properties:

1. On the Condition property, set and equation like this: ENVIRON="Dev"
2. On the TargetName property, set the value to "environ.config"

Obviously, your Condition equation will change for each file.  For the Prod.environ.config file, the Condition property will be ENVIRON="Prod".

 

Step 7: Finally, build your MSI and test it out.  When you choose, say, the UAT environment, make sure that your UAT config file gets deployed and renamed appropriately.  Attached is a sample app for your perusal.
 

 

MSIEnviron.zip (568.92 kb)

If you plan to write WCF services that will be consumed by clients of technologies other than .NET--and would like to include some level of security, like message signing (via X.509 certificates)--chances are you'll have to find some way to emit a BinarySecurityToken value in your responses.

When I first configured the security of my service, I went with a custom binding and a configuration like this:

<binding name="CustomBindingForX509">
<textMessageEncoding messageVersion="Soap11" />
<security allowSerializedSigningTokenOnReply="true" authenticationMode="MutualCertificate"
requireDerivedKeys="false" securityHeaderLayout="Lax" messageProtectionOrder="EncryptBeforeSign"
messageSecurityVersion="WSSecurity10WSTrustFebruary2005WSSecureConversationFebruary2005WSSecurityPolicy11BasicSecurityProfile10">
<localClientSettings detectReplays="false" />
<localServiceSettings detectReplays="false" />
<secureConversationBootstrap />
</security>
<httpTransport />
</binding>

This seemed to make sense (as far as WCF configuration can make sense, anyway): I was sharing certificates with my client (a Java Axis2 client), hence the MutualCertificate setting seemed appropriate.  I was also going for the lowest common denominator SOAP settings (as most folks in the interop space seem to recommend), so I went with those recommended SOAP settings.  This configuration had the effect of rendering my response to look as such (I only show the SOAP header section since it is what's relevant here):

<s:Header>
<o:Security s:mustUnderstand="1" xmlns:o="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
<u:Timestamp u:Id="uuid-5965cceb-61d9-4d3f-a503-c3f4dc7fe08a-3">
<u:Created>2008-07-17T20:33:42.153Z</u:Created>
<u:Expires>2008-07-17T20:38:42.153Z</u:Expires>
</u:Timestamp>
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
<SignedInfo>
<CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"></CanonicalizationMethod>
<SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"></SignatureMethod>
<Reference URI="#_1">
<Transforms>
<Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"></Transform>
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"></DigestMethod>
<DigestValue>3dcC17frvtyzp8G+kR5otzreQf0=</DigestValue>
</Reference>
<Reference URI="#uuid-5965cceb-61d9-4d3f-a503-c3f4dc7fe08a-3">
<Transforms>
<Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"></Transform>
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"></DigestMethod>
<DigestValue>h/DtKybbi4Q3RRtYKm26SGM2mcM=</DigestValue>
</Reference>
</SignedInfo>
<SignatureValue>IRlfHoVu/JispcD5CdMCKnbHNZcSVVNNLBtXbnP3fcid+nPi1F4WNGVsHjkF6PnaIzKM/5j2Vhnxbkm1tTwFjeKelQipCHErrwXsxOKMaVKlP/2gjeiJ0K2kkEO7LIUIcmqQ9MNx/AfGr9zE4c6EPGrkbPJVYLvra5jUhypMAcM=</SignatureValue>
<KeyInfo>
<o:SecurityTokenReference>
<X509Data>
<X509IssuerSerial>
<X509IssuerName>CN=Sample Service, OU=Rampart, O=Apache, L=Colombo, S=Western, C=LK</X509IssuerName>
<X509SerialNumber>1187603713</X509SerialNumber>
</X509IssuerSerial>
</X509Data>
</o:SecurityTokenReference>
</KeyInfo>
</Signature>
</o:Security>
</s:Header>

The problem is, my client didn't like these settings and kept throwing the error "The signature verification failed".  I suspect the client didn't like this response because the MutualCertificate setting seems to want the client to look up the certificate via distinguished name or serial number to verify that the message was signed appropriately.  Java clients, and apparently a few other technologies, don't seem to work that way.

So, what to do?  Well, eventually I found this post describing a similar problem between a WCF service and an SAP NetWeaver client.  Part III of the post describes what they did to resolve the signature verification problem: namely, get the WCF service to inject a BinarySecurityToken instead of the SecurityTokenReference (with issuer name and serial number).

I'm not totally fond of their implementation--they did the old school write-a-console-app-to-host-my-WCF-service approach--but this gave me an important clue to how to inject the BinarySecurityToken: use the AsymmetricSecurityBindingElement class!  Wow, why didn't I think of that?  That's fairly...uh...obvious.

Ok, so how do I use this AsymmetricSecurityBindingElement class?  I know I don't want to write a console app just to plug in this functionality--that's what IIS is for.  Guess I'll have to go to a custom BindingElement extension (see the attachment for the code and thanks to Scott, the Microsoft tech who wrote it--and helped me with this problem):

(excerpt from the client and service configurations)

<extensions>
<bindingElementExtensions>
<add name="MySecurityBindingElement" type="MySecurityBE.AsymetricSecurityBEExtentionElement, MySecurityBE, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" />
</bindingElementExtensions>
</extensions>
<bindings>
<customBinding>
<binding name="MyCoolBinding">
<MySecurityBindingElement/>
<textMessageEncoding messageVersion="Soap11"/>
<httpTransport/>
</binding>
</customBinding>
</bindings>

But wait, there's more!  It turns out that you don't even need to write your own custom BindingElement.  It turns out that the authentication mode MutualCertificateDuplex makes use of the AsymmetricSecurityBindingElement class.  What?  Didn't you know that?  So, all you really have to do is expose an endpoint with this kind of binding and you're set.  So, this service configuration:

<binding name="CustomBindingForX509">
<security authenticationMode="MutualCertificateDuplex"
requireDerivedKeys="false"  messageProtectionOrder="EncryptBeforeSign"
messageSecurityVersion="WSSecurity10WSTrustFebruary2005WSSecureConversationFebruary2005WSSecurityPolicy11BasicSecurityProfile10"/>
<textMessageEncoding messageVersion="Soap11" />
<httpTransport  />
</binding>

Will render this response (again, I'm just including the header for brevity):

<s:Header>
<o:Security s:mustUnderstand="1" xmlns:o="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
<u:Timestamp u:Id="uuid-39531f92-c0d4-4129-b491-6222c06d3bf5-1">
<u:Created>2008-07-25T16:03:59.959Z</u:Created>
<u:Expires>2008-07-25T16:08:59.959Z</u:Expires>
</u:Timestamp>
<o:BinarySecurityToken>
<!-- Removed-->
</o:BinarySecurityToken>
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
<SignedInfo>
<CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"></CanonicalizationMethod>
<SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"></SignatureMethod>
<Reference URI="#_1">
<Transforms>
<Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"></Transform>
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"></DigestMethod>
<DigestValue>2x4uPP0r/Zo7auuboFg+8h0k3Yo=</DigestValue>
</Reference>
<Reference URI="#uuid-39531f92-c0d4-4129-b491-6222c06d3bf5-1">
<Transforms>
<Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"></Transform>
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"></DigestMethod>
<DigestValue>Z161SvyizqMC3alennK2c6FLiZg=</DigestValue>
</Reference>
</SignedInfo>
<SignatureValue>EDpLDry/QuwxVuXe+/0LZrmrLkTcoZ1Ls45qvu+RebTRFfkq8HksKMN3Ip4T2begyDCLfGOTpEHfX/ohyMS7HIsxluyIwJ971kyLVt6nUZPfjqQ3iD3hCI2cCSRtNbC1p+aZDr3Tn/KbLxjWQ4aFfm7lRKbLGeVDEY5BJYyVCqY=</SignatureValue>
<KeyInfo>
<o:SecurityTokenReference>
<o:Reference ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3" URI="#uuid-f32fc9b9-695e-4542-98bb-acf40424321b-2"></o:Reference>
</o:SecurityTokenReference>
</KeyInfo>
</Signature>
</o:Security>
</s:Header>

Note that the response now includes the BinarySecurityToken and, ironically, has removed the x509 name and serial number data.  Don't worry about that "removed" comment, the binary token was sent to my client, it's just that WCF automatically removes privacy information from its logs--and I'm pulling this data from the log files.  For more info on privacy removal, see here.

Now, my non-.NET clients are happy, but I've just hosed my .NET clients.  From what I'm told, duplex mode is no walk in the park for .NET clients.  So, what to do?  Well, I'll tell you what I plan to do: just expose another endpoint.  If you're a .NET client, you'll get a traditional MutualCertificate binding endpoint.  If you're not a .NET client, you'll get the duplex endpoint.  The custom extension is nice, but not absolutely necessary at this point.

AsymExample.zip (899.63 kb)

Maybe this is obvious to everyone but me because I've found no discussions on the topic...or maybe my googling skills just stink...or maybe both...but after looking at the markup in some of SharePoint's ASPX pages and seeing neither a CodeBehind nor a CodeFile attribute in the Page Directive, it occurred to me that at least precompiled ASPX pages don't need either of these attributes.  The required attribute is Inherits.  Presumably, the .NET runtime uses the fully qualified assembly name in the Inherits attribute to discover the code behind for the requested page.  

Here's what I mean...

When I start a new Web Application Project in Visual Studio 2008 (or add a new page to such a project) and look at the markup in the ASPX page, I see a page directive declaration like this:

<%@ Page Language="C#" AutoEventWireup="true" CodeBehind="Default.aspx.cs" Inherits="Examples.CodeBehindAttrTest.Default" %>

I can jump to the code-behind file (Default.aspx.cs) and add this code to the Page_Load event:

protected void Page_Load(object sender, EventArgs e)
{
Response.Write(String.Format("The time is: {0}", System.DateTime.Now.ToString()));
}

I can compile and run my project, browse to the default.aspx page, and see the timestamp print out with no problem.  

So, what happens when I remove the CodeBehind attribute?  Well, the very same behavior happens.  This makes sense, too, because I don't deploy CS files to my production Web servers yet I make great use of code-behind files.  Of course, Microsoft basically says as much:

"This attribute [CodeBehind] is not used at run time." (from the Page Directive reference)

For your Web Site projects, I assume you could equally remove the CodeFile attribute, but that appears much stickier, what with having to precompile the site, setting the Inherits attribute correctly, and all.

The drawback of removing the CodeBehind attribute from your pages seems to be one of development-time convenience.  Without knowing what code file represents a given ASPX page, should I, say, try to add a click event handler to my server side button by double-clicking the button in the Design tab, Visual Studio will add server-side code inline to my ASPX page instead of the default behavior of taking me to my code-behind page.  If I cut and paste the inline code, drop it into my code behind page, recompile, and run the app, the event will fire as coded in my compiled DLL.  Visual Studio is even smart enough to declare my button control in the designer partial class.

Some time ago, Phil Haack posted a really cool entry on the System.Web.Routing feature, new in .NET 3.5 SP1.

In his post, he noted a "subtle potential security issue" where you might think you've secured a particular directory via a nested web.config and appropriate <authorization> element, but, in reality, you've totally circumvented that security.  Phil then re-included his security check by calling to the UrlAuthorizationModule.CheckUrlAccessForPrincipal method in his IRouteHandler implementation to determine if the user has permissions to the web resource being requested.  Here are two alternative approaches without having to add the UrlAuthorizationModule code:

Option 1: Change the "BackDoor" Route
Since the rule is to deny all requests to resources in the Admin sub-directory, if we change the route slightly to this:

routes.MapWebFormRoute("Secret", "admin/BackDoor", "~/Admin/SecretPage.aspx", false);

we can get the desired result:

 

Option 2: Add a Location Path to the Authorization Configuration
Leaving the Backdoor route as it is in the original demo code, another approach to take would be to add a <location> element around the authorization rule.  Thus, in the parent web.config file, we could add this configuration:

  <location path="backdoor">
<system.web>
<authorization>
<deny users="*"/>
</authorization>
</system.web>
</location>

and achieve the desired result:

 

 

All in all, though, I'm glad Phil chose the route he did because I had the chance to learn about the UrlAuthorizationModule.

 

I always forget this little nugget, so I'm going to dump it out here...


For those of you arriving late, MSBuild is the build engine for .NET 2.0 and above.  You'll find the executable in %windir%\Microsoft.NET\Framework\v2.0.50727\MSBuild.exe.

To use MSBuild to build your assemblies, you'll need to write MSBuild script in the form of XML.  What's nice about Visual Studio, though, is that Visual Studio pretty much writes your MSBuild script for you as you code your project.  If you drop your project files (CSPROJ for C# projects) into Notepad, you'll see what I mean.

Now, we all know that projects are housed under a solution described by a SLN file and we typically build all our projects at once by building the solution.  So, it stands to reason that the SLN file is persisted as MSBuild script, too, right?  Wrong.  Just drop that sucker into Notepad--that's not MSBuild syntax...I don't know what that is!  So how can MSBuild build an entire solution from an SLN file that's not even MSBuild script?

The secret is that apparently MSBuild, on-the-fly, converts the SLN file to MSBuild script then runs that script to generate the necessary output.  By default, we never see this converted file; however there is a way to see it.  Follow these steps:

1. From the command line, type: set msbuildemitsolution=1
2. Now run MSBuild: msbuild Solution1.sln
3. Look in the directory of your SLN file and you'll find Solution1.sln.proj (a .cache file is also created which appears to be a copy of the .proj file)

Thanks to Sayed Ibrahim Hashimi for blogging about this.

The next question is, of course, should I generate one of these PROJ files first, then run MSBuild against that file to build the artifacts of my solution--particularly if I need to do some operations at the solution level before, during, or after the build?  The answer is: I'm not sure.  I recall seeing some posts from folks who did just this and got some unexpected behavior (try googling msbuildemitsolution).  So, I would think that the safest course of action would be to customize you MSBuild script (CSPROJ files) as much as you can first.  If you can't quite address all your needs at the project level--say, moving different reference files around or whatever--I might consider writing a batch file around the whole process to see if that can better address your requirements.

I found this news a little startling, but certainly understandable.  It seems Red Gate Software is taking ownership of Lutz Roeder's .NET Reflector.  Fortunately, Red Gate will continue to offer a free version of the product but will no doubt offer a professional (pay) version, as well.  I'm reminded of that one time, at band camp, when Microsoft acquired Sysinternals.  Fortunately, those utilities are still free.

Microsoft just released .NET 3.5 SP1 and Visual Studio 2008 SP1.  While scrolling through the Overview section to see what's new in each service pack, I saw this:

VSTA 2.0 SDK

Huh?  Now, I've heard of Visual Studio Tools for Office (VSTO) before and I attended a DevCares.com event not long ago on VSTO, but I've never heard of VSTA.  Did Microsoft do another name change?

Apparently not.  According to this article:

"The same team that created Visual Studio Tools for Applications also developed Visual Studio Tools for Office and the two technologies share a common architecture. However, Visual Studio Tools for Office is designed for developers who want to include Microsoft Office in custom solutions, while Visual Studio Tools for Applications is designed for end users of any application that includes it. For example, an accountant could add a new capability to accounting software by writing a function, without having to involve the company's development department. End users add new functionality by creating add-ins."

So there you have it.  With these new tools coming out for much easier development on the Office platform, it's probably time to take a new look at making Office a front-end for some of our solutions.  You could make the same argument for SharePoint, but I think I'll leave that one alone for now.