hash_bucket()

Archive for the ‘.NET’ Category

It’s been quiet here for so long… When I look back at the posts, the fact that just the first page covers as much as 7 years is truly… humbling.

I was thinking about writing a post about the events of the past 7 years, but seriously who really wants to read about that? :) Better to look ahead.

I’ve just built a new gaming rig for the family, my first PC build in over 8 years. This woke again in me the desire to code more, and I’ve been dipping my toes back in .net over the past month or so. With that, I’ve decided to get serious (within hobby limits) about building out a tool to help S monitor her sickness and flares. Who knows, maybe it will turn into something I can release to a wider audience in the future…

For now, that’s it.

Advertisements

Getting the following error when you deploy your first asp.net 4.0 website:

Unrecognized attribute ‘targetFramework’. Note that attribute names are case-sensitive.

is most likely because of either of 2 reasons:

1. You installed the .net 4.0 bits after IIS was set up, resulting in the wrong version of the .NET framework beeing registered with IIS.

Most often the above results in conflicting versions of the framework, and so the easiest way of solving this is to re-register the .NET extensions with IIS using the aspnet_regiss tool. Make sure you run it from an elevated command prompt and that you use the correct version (in the v4.xx folder that is, not the v2.xx one). On my dev machine this tool is located in:

C:\Windows\Microsoft.NET\Framework64\v4.0.30319

and you run it with the -iru flags like so:

aspnet_regiis.exe -iru

2. You haven’t set the framework of the IIS application to the correct version of .NET (4.0 that is)

Change this using either the IIS Manager or the command line. In IIS Manager you select ‘Application Pools’, click the Application you’ve pointed you site to use, select ‘Basic Settings’ in the ‘Actions’ pane and change the ‘.NET framework version’.

This post over at MSDN should also be of great help. Gotta love Microsoft’s documentation!

http://msdn.microsoft.com/en-us/library/dd483478(VS.100).aspx

Here’s a little gem.

Most people like to keep their unit test assemblies and code separate from the code being tested (maintainability is such a nice thing). This however raises the issue of how to write tests for methods and classes that are marked internal.

Lots of different approaches exist, such as editing the *.csproj file by hand to include (inject) the code file containing the tests in to the code being tested. This, however is not a very smooth approach.

Thankfully there is a much easier approach using a technique called Friend Assemblies. Basically it’s a way of saying that Assembly A and Assembly B are friends, meaning that B can peek into A’s little secrets marked Internal.
Here’s how to set this up:

1. Add the Assembly Attribute ‘InternalsVisibleTo’ to the assembly being tested:
This goes into the file ‘AssemblyInfo.cs’, an autogenerated file in the Properties folder of your project.

[assembly: InternalsVisibleTo(“Tests.dll”)]

2. Make sure that the assembly containing the tests reference the assembly being tested, and that the output matches the name you typed in the Assembly Attribute (in this case ‘Tests.dll’).

One good thing to know is that sometimes your assemblies fail to make friends because the output of you test assembly has not been explicitly named. In such cases you should make sure to compile the test assembly using the ‘/out:’ switch.
/out:Tests.dll

As always, MSDN has the full story here:
http://msdn.microsoft.com/en-us/library/0tke9fxk(VS.80).aspx

and here:
http://msdn.microsoft.com/en-us/library/system.runtime.compilerservices.internalsvisibletoattribute.aspx

This article will introduce the Conditional Attribute and give an example of its usage. The technical level is kept low to make the text as accessible as possible. More info can be found in the official C# Programming guide, in particular the section called ‘Conditional’.

When it comes to debugging, the world (of IDEs) is full of tools to make life easier for us as developers. The latest version of Visual Studio (2008) features a vast array of built in debugging aids that help diagnose and keep track of a running application/assembly. This is all well, and maybe what I am about to say next may sound a bit old or odd, but I for one would never do away with my trusty old output console. I have talked about this before in a post that gave a brief walk through on how to open console windows from an existing and running application in Windowed mode (that is sporting one of those fancy graphical interfaces that seem to be so in fashion lately ;) ).

I have written a small dll that I hook up to must of my projects, through which you can ‘report’ debugging messages to one of 5 pre-defined ‘channels’. The report can be set to write to:

1) The Visual Studio output console (default)
2) A regular text file (you set the path)
3) A console window
4) Email
5) Wreq (my own custom project management tool)

This little tool uses reflection to keep track of what the application is up to, but you can also tell it to ‘report’ any message you choose at any time.

Eg:

DebugReporter.Report(
MessageType.Information,
“[Application Name]”,
“Creating and setting Auto Save path” +
“\nPath: ” + _path.ToString());

or:

DebugReporter.ReportMethodEnter();

DebugReporter.ReportMethodLeave();

One thing about reporting debug info this way is that when you switch to a Release build you want all of those messages to go away automatically, so that you do not have to comment out all these calls.

One way of acheiving this would be to use the #if-endif construct such as:

#if DEBUG
DebugManagers.DebugReporter.Report(
DebugManagers.MessageType.Information,
“[Application Name]”,
“Creating and setting Auto Save path” +
“\nPath: ” + _path.ToString());
#endif

This pre-processor directive would tell the compiler to skip the encapsulated block of code. However, in a typical small application I usually end up with a lot (hundreds) of calls like this and decorating them all with #if-endif just isn’t a very elegant solution. Fortunately the designers of the CLR thought about this and gave us a much better way of dealing with this situation.

One thing you can easily discern from the above code is that all these calls access the same static method on the same static class. Thus, instead of decorating all the method calls, what if we could decorate the method itself?

In .net there is a concept called Attributes that allows you to add custom behaviour and ‘properties’ to methods. The framework contains a lot of pre-defined attributes that deal with for example security, compiler-options, discoverability and much more. Also, as a developer you can define your own attributes, but that is beyond the scope of today’s topic. (See the ‘.NET Framework Developer’s Guide’, in particular the section on ‘Writing Custom Attributes’.)

One such pre-defined attributes is the ‘Conditional’ attribute. This works pretty much like an inverse version of the #if-endif construct. it tells the compiler when to, for example execute a particular method.

Note: This is not a pre-processor directive in the form we know it from of a C/C++, in fact the .net framework as no such concept since the code is JITed upon execution. Thus the above statement that the compiler executes a piece of code is sort of correct, if by compiler to mean the CLR, and by executing you mean Just-In-Time compilation… The C# Programming Guide calls this a ‘preprocessing identifier’.
(See the ms-help page ms-help://MS.VSCC.v90/MS.MSDNQTR.v90.en/dv_csref/html/e1c4913b-74d0-421a-8a6d-c14b3f0e68fb.htm)

When using the Conditional attribute you define a constant condition that has to be met for any code-path that access the decorated mehod to be executed. Naturally this can help us in the debuggin scenario. One such constant that is defined automatically when building a Debug build in Visual Studio is the DEBUG constant. Thus we can do the following:

[Conditional(“DEBUG”)]
public static void Report(…)
{

}

Using this attribute is what invokes the magic. Now, if the DEBUG constant is not set, any method call to the Report method will simply be excluded from the build, keeping our Release build nice and neat and without cluttering the code with those #if-endif. In fact, the method itself wont event be present in the emitted MSIL :). That, is clean!

There are a few restrictions on using the Conditional Attribute. In particular, the method you want to decorate must have a return type of Void.

Note: This actually makes a lot of sense as the method will no longer be available and the compiler would have a hard time tracing all the possible usages of the eventual return value that might be expected by later code…

I still see a lot of (c#) code written that is full of #if-endif (almost exclusively to defer execution paths in/out of debugging), but I would highly recommend you start experimenting with using the Conditional Attribute instead (where applicable of course ;).

There are still some legitimate use for the #if-endif of course, for example when you want to skip a particular code-block within a method, or when the method you call has a return type other than Void. Thus you should not rely on the Conditional attribute to solve all of your conditional execution, but keep it around as a powerful and simple technique. Also, it might give you an excuse to learn more about the power of Attributes in .NET, and how to write your own custom Attributes.

There’s something nice about walking through the great check in hall at the Venetian Hotel in Las Vegas, stepping up to the Invited Guests desk, showing your passport and here the person on the other side saying ‘Welcome back, Mr. J’. We’ve been expecting you.

Not that I’m such a regular visitor to neither Vegas nor the Venetian in particular, but since this is my third time at Mix, I assume their database records of previous guests picked me up. Nice conference start…

Actually the conference doesn’t start until tomorrow, but I had some appointments set up for the day before the event so i decided to come here a bit early. Every year at Mix, the people attending by invitation from Microsoft Japan gets together for a Japanese group dinner sort of thing. A relaxed little social gathering where the usual suspects gather to catch up on what’s happening in .Net development in Japan. I was very happy to see that this year the group had grown, meaning hopefully that the number of devs working with .Net (in particular 3.0/3.5) and Silverlight is growing too.

Other things worth noting, I did get a chance to discuss blue hair and table saws with Adam, age with Laurence and social experiments with Gilber.

Looking forward to tomorrow. :)

A lot of people have asked me to provide a sample where an XBAP communicates with a WebService. Unfortunately I can never seem to find the time to write one up, so I was very happy to stumble upon this (apparently unofficial) sample provided by a person who claims to be MS. I cannot confirm who this person is, nor that the sample is really provided by MS, but if you’re interested have a look:

http://cid-42ea0c790532f651.skydrive.live.com/self.aspx/Public/XBap2WCF.zip

This sample was referenced in the following post:

http://www.codeprof.com/dev-archive/218/153-119-2183881.shtm


.

This blog has no clear focus. It has a focus though, it's just not very clear at the moment...

Dev Env.

Visual Studio 2008 Prof / NUnit / Gallio / csUnit / STools (ExactMagic) / doxygen / dxCore / TypeMock / TestDriven.net / SequenceViz / CLRProfiler / Snoop / Reflector / Mole / FxCop / Subversion / TortoiseSVN / SlikSVN / CruiseControl.net / msbuild / nant

Blog Stats

  • 81,435 hits