SocketException on host over SmartPass VPN

I have ASP.NET code that attempts to access a particular database over a SmartPass VPN connection. After trying several different ways to avoid the "host not found" SocketException, I copied the ASPX page to a server inside the VPN -- the page worked with no problems. Then I copied the same code into a simple exe (console app); again, it worked fine. I'm at a loss of what the problem is. I know that the ASPX code has DnsPermission, etc., but I haven't been able to find any other clues via google, etc. If you have any ideas, please send them my way.

SQL 2K: User Defined Types are such a pain!

The promise of User Defined Types is huge, but the headaches may not be worth the effort. With one of my clients we need to be able to easily change UDT definitions and get It Just Works (IJW). For example, we create a StringType_50 that can either be varchar(50) or nvarchar(50). Works fine for table definitions and for sproc params. But if you need to create a temp table in a sproc, you can't use the UDTs. Well, you can create the UDT in the tempdb. We have very restrictive production security issues, and I don't know what the issues are re: ability to create types in tempdb. I will probably mess around with that option later. For now, however, IJW just isn't there w/UDTs.

Don't use SQL Server 2000 Table Variables

SQL 2k's table variable is handy in some ways -- less locking required during transactions, fewer sproc recompiles than temp tables. However, I don't recommend using table variables because:

• Table variables cannot be defined using User Defined Types. We use UDTs frequently to enforce consistency in even the smallest dbs. Table variables force you to break this best practice and reverse its benefits.
• Unclear that the variable is a table. The # (or ##) prefix of temp tables gives immediate indication that it is a table. Although good naming conventions could be used to reduce this, naming conventions aren't validated by the compiler.

Power Blogger?

Am I a power blogger or what? It's only been 6 MONTHS since my last entry. Oh yeah -- all over this bloggin' thing.

MS Enterprise Library for GAC

Since I need to use E/L for several apps on a current project, I want to GAC the whole thing. I also want to make it easy for all the devs (of course). Easy solution, right? Just create an installer to gac the E/L assemblies. Well, I had more trouble than one would expect. One of the major hurdles was fairly obscure, so I want to record it here.

Update App Config After GAC'ing Enterprise Library

The biggest gotcha I ran into is that using the E/L config tool for an application sets PublicKeyToken=null in the reference info. This will cause exceptions similar to "Logging.Configuration.ConfigurationException" to occur. To correct this problem, add the PublicKeyToken from the GAC for each E/L assembly to the appropriate location in the app's config files.

ASP.NET Apps within SharePoint

While designing a digital asset management system for one of my clients, I considered running the ASP.NET app within SharePoint by simply instructing SharePoint to exclude the path. This is a pretty good idea, if the app can live within the confines SharePoint imposes. Authentication & Session, for example, can't be controlled at the this level.

If your app needs to impersonate, the capabilities are limited. Setting impersonation in the identity element causes the Windows Identity to be IUSR_. Leaving impersonation off causes the Windows Identity to be that of the App Pool (NETWORK SERVICE in my case). In either case, the Page and Thread Principals are empty since the Directory Security setting in IIS allows anonymous. Changing the Dir Sec setting does as you'd expect -- the Page and Thread Principals are set appropriately, impersonation is set, etc. But, now the entire top-level SharePoint site requires authorization (no anonymous access).

ASP.NET Impersonation and Principals

Every now and then I write a simple app to remind myself of what the principals are for the various impersonate config options. Maybe in the future I'll remember to look here.

Assumptions:

• VRoot requires authentication (anonymous disabled)
• VRoot's App Pool identity using NETWORK SERVICE
• "IEUser" is the end user
• "ImpersonatedUser" is the user config'd in the identity element

Scenario	Page User	Thread CurrentPrincipal	WindowsIdentity
impersonate=false	IEUser	IEUser	NETWORK SERVICE
impersonate=true; userName not set	IEUser	IEUser	IEUser
impersonate=true; userName set	IEUser	IEUser	ImpersonatedUser

So, the identity of System.Security.Principal.WindowsIdentity is the only one that changes. Page.User should typically be used for IsInRole checks.

SharePoint & WSS_Medium

As I mentioned in an earlier post, I've been trying to determine the overhead involved with updating data via SharePoint WebParts vs. ASP.NET WebForms. To get started, I created a simple WebPart to render the request's query params to a HTML table. So, the first problem I ran into is that a WebParts do not have access to the params collection due to CAS. When I exec'd the page, an error regarding "LinkDemand for AspNetHostingPermission failed" (or similar). So, my WebPart didn't have this permission. I added it to GAC, but elevating it to Full trust probably isn't a good idea. Thanks to several blog posts (Debugging Web Parts - a full explanation of the requirements in particular) I changed the system.web/trust config from level='WSS_Minimal' to 'WSS_Medium' This brought my WebPart back to life, and I believe I'm operating in a least required security mode now.

Applications in SharePoint

I'm architecting a solution for a customer which would benefit from several features in SharePoint 2003 (Tasks, Alerts, doc repository, etc.) The solution will need several of these concepts, and I hope SharePoint's features will be a good match. However, I'm concerned that data entry pages will be complicated by the fact that SharePoint uses WebParts in zones on the page. This is similar to other frameworks I've used, yet so far I have not been able to determine the amount of additional overhead required to do data entry in SP.

WebParts are very similar to Server Controls in ASP.NET -- code in an assembly writes HTML to the output stream. No big deal from the output standpoint, but you don't get as much of the input benefits from ASP.NET controls (DataGrid is a good example).

Big Gaps

Wow! It's amazing how long the "dry spells" are between my blogging activities. Too busy!

XSLT, XPath and GUID's

Ahh, GUIDs. We love 'em; we hate 'em. Actually I usually love them, but querying for GUIDs in XML is fraught with peril. Consider a simple case of seaching for a Person node by the value of an attribute:

<xsl:template match="//Person[@PersonID='3'] >
...
</xsl:template>

But what if the unique identifier for Person nodes is a GUID?

<xsl:template match="//Person[@PersonID='
{4C22F4FA-0C4A-4FCF-85DF-F9B7A902244E}'] >
...
</xsl:template>

• What GUID format is used in the XML?
• Bracket notation?
• Hyphenated?
• Mixtures?
• With which casing are the alphabetic portion of the hex values stored in the XML?
• Upper case?
• Lower case?
• Mixture?

As you can see from just these two items, the matrix of problems expands rapidly. In the particular case I am dealing with, I am able to control format (bracketed, hyphenated), but not case. I have had to assume that case will be either upper or lower, but that mixed case will not occur (a fairly reasonable assumption since the GUIDs are not manually edited; for code to render mixed case it has to do extra work). So, my XSLT file finds the appropriate node by this method:

<xsl:param name='FindThisGuid'>
<xsl:variable name='UCaseGuid' select='translate($FindThisGuid, "abcdef", "ABCDEF")'>
<xsl:variable name='LCaseGuid' select='translate($FindThisGuid, "ABCDEF", "abcdef")'>
<xsl:template match='Person[@PersonID = $UCaseGuid) Person[@PersonID = ($LCaseGuid)]>
...
</xsl:template>

Now the Good News: XSLT 2.0 will hopefully resolve this issue by promoting GUID to a first class citizen (actual type).

IE Gotcha! Do Not Use Self-Closing Script Tag

I recently had the (ahem) pleasure of helping a colleague debug a JavaScript problem. The issue was the he had multiple JavaScript blocks on a page like this:

<script type='text/JavaScript' src='uitools.js' />
<script type='text/JavaScript'>
function DoSomething() {
//...
}
</script>

Seems harmless enough, right? For the longest time we could not determine why DoSomething was not accessible to page elements. We tried all kinds of things until we stumbled upon a surprising resolution. We began to drill in on the issue when I moved the DoSomething function into the upper script block (which required breaking open the self-closing script tag). Suddenly, page elements could use the function successfully. After we moved the function back to its rightful home, everything still worked. Then I realized that the only difference was that the upper script block was no longer self-closing. When I converted it back to self-closing, sure enough the page stopped working again.

For some reason IE (and possibly other browsers) does not handle self-closing script tags in an XML compliant manner. Go figure!

BP: 15 Minutes Isn't Enough

One of the pitfalls of the internet era is that we easily forget that communication takes time. Today's case in point has to do with product build announcements. On my current project, the dev team's "practice" is to send email announcing, "We're going to sync & build in X minutes. Don't check in anything until we send email announcing a successful build." (Formerly X was 5 minutes; recently it has trebled to a whopping 15. The fact that the dev team builds on a random schedule is poor practice in the first place.)

The person who does these builds seems to think that everyone receives the email instantaneously and that they will act on the information immediately. As is predictable, however, the builder frequently sends email along these lines, "Everybody stop checking in! I haven't been able to build." or "We will not have a build today because too many checkins occurred after the cut-off."

The problem is that people are not immediately in tune with email in some Borg-like fashion. We need consistent, dependable builds; but we're trying to deliver randomly.

How much will break?

I don't claim to be an expert in javascript, but I continue to find myself working with it. As I was working on a separate issue, I saw that the language attribute of <script> has been depricated as of HTML 4.01. Ok. I can switch to type='text/javascript' easily enough. The issue that got my attention however, is that XHTML 1.0 does not support the language attrib. So, tons of existing javascript in HTML pages will be rejected in the XHMTL world. That will create a significant barrier to adoption for XHTML.