Room of a pleinolijf

Ask yourself this: how do I want to be remembered ?


Leave a comment

Be wary of closures when using delegates

Just recently, I got caught out by a closure.  A closure is a piece of code that can be ‘executed later’, while still retaining the environment in which it was created.  A lot of developers mistakenly think anonymous delegates, like lambda expressions, are by definition closures.  They can be, but don’t have to (and usually aren’t).

I’ll illustrate with the actual code snippet that caught me out.  Unfortunately, at my current client, I can’t make use of the excellent Visual Studio add-in ReSharper, which would have alerted me on this with a “Access to modified closure” warning.

foreach (string keyword in keywords)
{
   ToolStripMenuItem keywordTsmi = new ToolStripMenuItem(text: keyword, image: null,
      onClick: (sender, e) => Clipboard.SetText(keyword));
   keywordsTsmi.DropDownItems.Add(keywordTsmi);
}

In this bit, I am filling up a context menu with new sub menu items, containing keywords that are copied to the clipboard when clicked on.

Obviously, this compiles just fine, and the submenu is correctly filled with all the distinct keywords.  However, no matter which keyword you click, it would always copy the last keyword in the list.  With this functionality being not-very-much-in-your-face, it slipped through (user) testing.  I’ll be the first to admit we need more unit tests 😉

The solution is dead-simple:

foreach (string keyword in keywords)
{
   var keyw = keyword;
   ToolStripMenuItem keywordTsmi = new ToolStripMenuItem(text: keyw, image: null,
      onClick: (sender, e) => Clipboard.SetText(keyw));
   keywordsTsmi.DropDownItems.Add(keywordTsmi);
}

By assigning the value to a local-scope variable, the compiler will save a separate reference for each keyword, instead of only one that gets modified with each loop (hence the ReSharper warning).  Because the latter is simply the standard behaviour when you use a delegate with a variable like that.


Leave a comment

Suppress Compiler Warnings in Visual Studio

Just a quick post to put this out there.  Chances are you already know of this, but I can imagine far from everybody does.

 

When building a project or solution, Visual Studio will report on what’s happening in the Output window.  (By the way, you can control the verbosity of said window in the Tools – Options… – Projects and Solutions – Build and Run screen.  And the first thing I do on a new system configuration, is enable the ‘Show Output window when build starts’ option in the screen before that.)  It will print informational lines of text, but also, and more importantly, warnings and errors while compiling.

Obviously, your attention should be focused on the errors, as they will likely prevent you from running your application.  Call it neurotical behaviour, but I always aim to have an as clear Output window as I can, so the warnings receive equal attention from me (although not as diligently of course).

But sometimes warnings will keep being generated by Visual Studio, even though you intentionally wrote the code the way you did.  An example can be fields that are declared and assigned, but only used in a

#if (!DEBUG)

statement, like a bunch of license key registrations meant for production.

 

 

To keep the warnings from always popping up in the Output window when building, use the #pragma preprocessor directive.

#pragma warning disable 414, 3021

You can get the warning numbers by building  your code. If you can’t or won’t, you can also wrap the code in question in a

#pragma warning disable

and

#pragma warning restore

‘block’. This will disable all warnings in between, so use with caution !

 

PS: VSCommands by Squared Infinity is a great extension for VS that will color-code the lines in the output window to increase readability.  You can even define your own custom formatting.


2 Comments

HttpContext.Current.Session is null, but it shouldn’t be

Annoying issue yesterday.  I was meaning to write a dead-simple web application in .NET 4.0 that talks simultaneously to a referenced .NET 3.5 assembly, and uses an in-house .NET 4.0 framework of services (also referenced).  The goal was to test the correct operation between these different .NET version assemblies.  In most cases, that’s not even a thing to consider, but we wanted to be absolutely sure.

When calling a method of the referenced 3.5 assembly, which acts as a facade between a client and a web service, there is code that uses the HttpContext.Current.Session.  I was assuming that with my test client, being a web application, this would be all fine and dandy, but apparently not.  The HttpContext Session was null.

The solution ?  Adding

<sessionState mode="InProc" />

to the client application’s web.config, in the <system.web> section.

 

It’s not clear to me what the cause of this is.  I strongly doubt it’s default configuration behaviour, and I’m sure it has nothing to do with the code of the referenced assembly.  From what I know and have read on the subject, the session would have been instantiated by starting the application…

If you have a clue, be sure to leave it in the comments.

 


Leave a comment

Inetinfo.exe Crashes On Certain Web Project

Great. Just spent a nice two hours figuring out why inetinfo.exe (the IIS process) crashes when I open a certain web project.

I went Googling, and after a while I found a KB article describing the exact problem I had, even with the exact same event ID’s in the system event log. But I couldn’t find a download, and even if I did, it was Windows Server 2003 only. Had something to do with an exploit in the SMTP service. Anyway, that didn’t help me.

So I tried something totally not logical: opening a different web application in my IDE. And bingo: it opened just fine. So maybe the configuration of the ‘bad’ project was defunct? -No. And so it should be, I hadn’t tinkered with it for a long time, so why would it suddenly not work anymore. (As the rest of this story will show, I forgot to check one setting.)

Then, my penny dropped (“mijne frang viel” -Flemish expression): I recently added another web site in IIS, besides the default one. This had to be done for another, single, project that used .NET 2.0. And indeed, the configuration for the ‘bad’ project was wrong: it said to use .NET 2.0, where it was previously using 1.1.

I suppose switching between the two sites fires a bug in IIS, overwriting some configurations…? I don’t know, but I’m fairly sure the config for the ‘bad’ project has stayed the same ever since it was created…

Anyhoo, another experience richer I guess.

Technorati Tags: , , ,


Leave a comment

Type Casting Performance in .NET

[ as taken from MSDN © Microsoft Corporation. All rights reserved. ]

The DirectCast keyword introduces a type conversion operation. You use it the same way you use the CType keyword, as the following example shows:

Dim Q As Object = 2.37		' Requires Option Strict to be Off.
Dim I As Integer = CType(Q, Integer)	' Succeeds.
Dim J As Integer = DirectCast(Q, Integer)	' Fails.

Both keywords take an expression to be converted as the first argument, and the type to convert it to as the second argument. Both conversions fail if there is no conversion defined between the data type of the expression and the data type specified as the second argument.

The difference between the two keywords is that CType succeeds as long as there is a valid conversion defined between the expression and the type, whereas DirectCast requires the run-time type of an object variable to be the same as the specified type.

In the preceding example, the run-time type of Q is Double. CType succeeds because Double can be converted to Integer, but DirectCast fails because the run-time type of Q is not already Integer. DirectCast throws an InvalidCastException error if the argument types do not match.

If the specified type and the run-time type of the expression are the same, however, the run-time performance of DirectCast is better than that of CType.

TechnoratiTechnorati Tags: , , ,


1 Comment

Visual Studio 2003 Web Forms Designer Error with Page Inheritance

When you use VS2003, and you are working on a project that uses page inheritance (replacing the standard System.Web.UI.Page by a BasePage class of your own), you probably have seen the following error when double-clicking an aspx page: “The file could not be loaded into Web Forms Designer” and some other blablabla…

I know of some workarounds, and this guy Tobin Harris [ tobinharris.com ] has summed them up all nicely on one page [ tobinharris.com ].

They are not a guaranteed solution however, but in many cases one of the workarounds might help you. If not the case, I read some other workaround somewhere on some site that I can’t remember 🙂  Here we go ! [ dotnet.org.za ]

It states that the problem is when your custom BasePage class is declared abstract, and this way, the Forms Designer can’t instantiate any of the methods, and thus is unable to build a view of the web page.
The workaround consisted of writing extra code like this:

#if(DEBUG)
public class BasePage : System.Web.UI.Page
#else
public abstract class BasePage : System.Web.UI.Page
#endif
{
#if(DEBUG)
public virtual void method1()
{
throw new NotImplementedException();
}
#else
public abstract void method1()
#endif
}

If you’re developing, you’re in debug mode, and that’s the only time you’ll need the Forms Designer. if you need that crap at all, cause basically it does more bad then good, but it also triggers and fires the annoying error message when directly viewing the HTML code. When deployed, you’ll mostly use a release build, and that’s when your BasePage class will be declared abstract, like it should be.

TechnoratiTechnorati Tags: , , , , ,