Miscellaneous Debris

Upgrading all projects to .NET 3.5

2008-05-25T08:56:14Z

A simple macro to change the Target Framework for a project from .NET 2.0 to .NET 3.5, hacked together in a few minutes. This will fail for C++/CLI projects, and possibly VB.NET projects (haven't checked). Works fine for regular C# projects, as well as web projects:

For Each proj As Project In DTE.Solution.Projects
   Try
       proj.Properties.Item("TargetFramework").Value = 196613
       Debug.Print("Upgraded {0} to 3.5", proj.Name)
   Catch ex As Exception
       Debug.Print("Failed to upgrade {0} to 3.5", proj.Name)
   End Try

Next proj

Why 196613, you ask? Well, when I see such a number my first instinct is to feed it into calc.exe and switch it to hexadecimal. And I was right: 196613 in decimal converts to 0x00030005 - You can see the framework version hiding in there. Major version in the high word, minor in the low word. The previous TargetFramework number was 131072 - 0x00020000, or 2.0.

(Nitpickers might point out that I could simply set it to &30005 rather than messing with the obscure decimal number. They would be correct - but I got to this number through the debugger, so that's how it will stay)

Sneaking past the SharePoint Usage Log

2008-04-16T15:13:16Z

I'm writing a piece of code that regularly polls a MOSS server and checks several files. This can happen quite a few times a day, and this totally skews my Usage Reports for my sites.

Does anyone know of a way to tell MOSS to ignore calls made by a specific user, a specific IP (my code runs on a dedicated server), a specific UserAgent or whatever?

Any signs of life for the SharePoint Extensions for Visual Studio?

2008-01-23T19:57:31Z

Has anything been released - or, in fact, talked about - since August's release of the v1.1 CTP?

Haven't done any web-part development in a while and wanted to get back in the game. I last used the v1.0 extensions, and was surprised that nothing much has changed in that field except for the CTP release, and even that can't be downloaded - I just get a broken link.

Seeking advice - strong names and config files

2007-12-20T11:48:49Z

I'll use my blog for a bit of fishing for advice and guidance on an issue that's been bugging me.

We've been moving towards using strong names on all of our assemblies. The benefits are obvious, and it's a must before we deploy to clients out in the wild.

The problem is that we have several different processes running, each with its own app.config or web.config file. These config files contain references to custom configuration sections, whether they're application configuration, Enterprise Library extensions or whatnot. Seeing as my DLLs are signed, I have to use the fully qualified assembly name in all my references. This means that in a nightly build scenario where my version number is bumped continuously, I have to change 5-6 references in 5-6 configuration files with every build.

Doing this kind of string manipulation on a large scale scares me, since it can break, or we miss something. I've tried using <assemblyBinding> and <bindingRedirect> directives, but they require a specific version to point to as well.

I'm sure I'm not the first person to encounter this problem. What are the solutions that you use to bypass this? Scripts as part of the automated installation? Moving all configuration sections to a separate assembly whose version is static? What's the least painful way to manage this?

System.Diagnostics.EventLogEntry and the non-equal Equals.

2007-11-25T18:12:21Z

Just a quick heads-up in case you're stumped with this problem, or just passing by:

The System.Diagnostics.EventLogEntry class implements the Equals method to check if two entries are identical, even if they're not the same instance. However, contrary to best practices, it does NOT overload the operator==, so these two bits of code will behave differently:

EventLog myEventLog = new EventLog("Application");
EventLogEntry entry1 = myEventLog.Entries[0];
EventLogEntry entry2 = myEventLog.Entries[0];

bool correct = entry1.Equals(entry2);
bool incorrect = entry1 == entry2;

After running this code, correct will be true while incorrect will be false.

Good to know, if you're reading event logs in your code.

Displaying live log file contents

2007-11-21T14:12:54Z

I'm writing some benchmarking code, which involves a Console application calling a COM+ hosted process and measuring performance. I want to constantly display results on my active console, but since some of my code is running out-of-process, I can't really write directly to the console from all parts of the system. Not to mention the fact that I want it logged to a file as well.

So I cobbled together a quick Log class that does two things - it writes to a shared log file, keeping no locks so several processes can access it (I do serialize access to the WriteLine method itself, though). I don't mind the overhead of opening/closing the file every time, since this isn't production code.

The second method is the interesting one - it monitors the log file and returns every new line that is appended to it. If no lines are available, it will block until one is reached. The fun part was using the yield return keyword, which I've been looking for an excuse to use for quiet a while now.

Note that there are many places this code can go wrong or should be improved. There is no way to stop it running, only when the application is stopped. I bring this as the basic idea, and it can be cleaned up and improved later:

   1: public static IEnumerable<string> ReadNextLineOrBlock()   2:         {   3:             // Open the file without locking it.   4:             using (FileStream logFile = new FileStream(Filename, FileMode.Open, FileAccess.Read, FileShare.ReadWrite))   5:             using (StreamReader reader = new StreamReader(logFile))   6:             {   7:                 while (true)   8:                 {   9:                     // Read the next line.  10:                     string line = reader.ReadLine();  11:                     if (!string.IsNullOrEmpty(line))  12:                     {  13:                         yield return line;  14:                     }  15:                     else  16:                     {  17:                         Thread.Sleep(100);  18:                     }  19:                 }  20:             }  21:         }

This method can now be called from a worker thread:

   1: private static void StartListenerThread()   2:         {   3:             Thread t = new Thread(delegate()   4:             {   5:                 while (true)   6:                 {   7:                     foreach (string line in Log.ReadNextLineOrBlock())   8:                     {   9:                         // I added some formatting, too.  10:                         if (line.Contains("Total"))  11:                             Console.ForegroundColor = ConsoleColor.Green;  12:                           13:                         Console.WriteLine(line);  14:    15:                         Console.ForegroundColor = ConsoleColor.White;  16:                     }  17:                 }  18:             });  19:    20:             t.Start();  21:         }

Another minor C#/C++ difference - adding existing files

2007-10-28T14:35:24Z

Another minor detail that bit me for a few minutes today. I'm posting this so I'll see it and remember, and possibly lodge it in other people's consciousness.

Using Visual Studio 2005, adding an existing .cs file to a C# project will cause a copy of that file to be created in the project directory. If I want to link to the original file, I need to explicitly choose Add As Link from the dropdown on the Add button.

C++ projects, however, have the opposite behavior. Adding an existing item in a different folder will add a link to the original file in the original location. To create a copy, manually copy it to the project dir.

That is all.

Another Sharepoint Web Services rant : untyped data vs. incompletely typed data

2007-09-06T13:18:37Z

Working with the Web Services in WSSv2 and v3 is an exercise in sheer frustration. I've written before about serious and glaring omissions in the Web Services API that Sharepoint exposes, but it's not only the things missing, it's the lack of consistency in the APIs that ARE implemented that's annoying.

For most of the APIs, the return value for most methods is an XmlNode, usually documented pretty well in the SDK. It means we have to fiddle with XML to extract data, but it's not so bad. For instance the Lists WS's GetListCollection() returns a known, documented, schema-linked XML containing many properties for a given list.

For some reason, though, the SiteData web service chooses to return data as typed objects instead - oddly named objects at that (_sList, _sWebWithMetadata[], and so forth), but only for SOME data. The GetSite() method, for instance, will return a typed metadata object for the site metadata and the list of Lists, but a completely untyped STRING containing XML data for the list of groups and group members.

Futhermore, these XML snippets are sometimes undocumented, and you have to try it out to see what you get. What you get, sometimes, is the same XML you would get from a call to a different web service, but stripped of the namespace - so even though it's the same structure, you can't use the same code to parse both.

Similarly the GetListCollection() method in SiteData. It returns a typed array of _sList objects which map to the XML that's returned from the ListsWS method, only for some reason, some oft the XML attributes are NOT mapped, and are inaccessible. So if I want to see whether a list is Hidden or not, I am unable to use the typed objects and have to resort to the loose XML manipulation.

Seriously, these rants are adding up. Does anyone know who's in charge of the web services for Sharepoint and why they're so badly designed? No consistency, missing functionality, bad documentation - what's going on here? This isn't v1, either, but very little seems to have changed since the original documentation for WSS v2 in 2003.

Return of the GC Hole: Another one from the C++/CLI trenches

2007-09-06T11:09:18Z

A few days ago I wrote of a GC hole I accidently created in my C++/CLI code (with thanks to commenter Nish for the name of the phenomenon). I had the following code snippet set inside a private function:

pin_ptr<Byte> pinnedBuffer = &data[0];
char* buffer = (char*)pinnedBuffer;

Because the pin_ptr went out of scope when the function ended, I had a pointer to a memory location that was quickly moved by the GC, and got me a whole buffer full of garbage. To avoid that, I moved those two lines of code to my main method and pinned it throughout that method.

I thought that was the end of that, but today I noticed that I was still getting garbage occasionally in my buffer. This stumped me for a bit - it seemed like the pin_ptr wasn't doing its job - until I noticed how my C++ code looked:

public void DoStuff (array<Byte>^ data)

char* buffer;

if (data.Length > 0)
{
pin_ptr<Byte> pinnedBuffer = &data[0];
buffer = (char*)pinnedBuffer;
}

// Now do stuff

For C++ programmers this is probably obvious. For me and other C# devs, not so much. C++'s scoping rules say that when the if block terminates, the pin_ptr<Byte> goes out of scope immediately. This causes the pinned memory to be released, and allows the GC to move my array. Meanwhile my unmanaged code goes over the buffer and reads data. If I'm lucky, the GC won't start until I'm finished and all is well. If the GC IS active, I can either get garbage data (whatever is now pointed to by buffer) or, even worse, an access violation if I now point to protected memory.

Windows Services, services.msc and the "This Service is marked for deletion" error.

2007-09-05T09:14:54Z

In my current project, we have a windows service that we are developing and debugging, which involves a lot of installing/uninstalling the service. One common problem when uninstalling a service is that while the uninstallation is successful, you still see the service listed in the Services console(services.msc). If you try to start it, stop it or uninstall it again (using installutil.exe or sc delete) you get an uninformative "This service has been marked for deletion".

The KB article about this problem suggests you restart the computer, which is pretty much overkill. Sure, it'll work, but you'll never find out what caused it in the first place. Turns out it's a pretty simple affair: just make sure you close the Services console, which apparently holds a handle of some sort to it. You don't have to do it before you uninstall. The minute you close the console, all services marked for deletion will be deleted, and all will be well.

When doing it on a server, it's important to make sure you've closed all Services consoles on all active sessions. I've seen this error happen when no console was open, and it was fixed by running Task Manager and killing all instances of mmc.exe. I could have logged on to the other sessions and closed it gracefully, but I was lazy. Did the trick.

Dynamically creating a Sharepoint Web-Service proxy instance

2007-09-03T16:55:35Z

In my current code, I find myself accessing many Sharepoint web services. In one run of code I can access 5-6 different web services on dozens of different sites, not necessarily even on the same server. Given that I find myself writing a lot of boilerplate code looking like this:

using (SiteData siteDataWS = new SiteData())
{
   siteDataWS.Credentials = CredentialsCache.DefaultNetworkCredentials;
   siteDataWS.Url = currentSite.ToString() + "/_vti_bin/SiteData.asmx";

   // Do something with the WS.
}

Seeing as this is quite wearisome, I've decided to go an genericize it. Given also that the name of the ASMX file for all Sharepoint services is the same as the name of the class to be instantiated, it gets even shorter:

1: public static WSType CreateWebService<WSType> (Uri siteUrl) where WSType : SoapHttpClientProtocol, new()
2: {
3: WSType webService = new WSType();
4: webService.Credentials = CredentialCache.DefaultNetworkCredentials;

5: string webServiceName = typeof(WSType).Name;
6: webService.Url = string.Format("{0}/_vti_bin/{1}.asmx", siteUrl, webServiceName);

7: return webService;
8: }

Line 1: Define a generic method that receives the type of Web Service and returns an instance of it. Note the generic constraints - the type must be a Web Service Proxy (SoapHttpClientProtocol) and must be instantiable. The last one is necessary for line 3 to compile.

Line 5: Get the name of the type - for our example above it would be "SiteData" - and build the URL based on the site URL and the web service name.

Now I can transform the above snippet to this:

using (SiteData siteDataWS = WebServiceHelper.CreateWebService<SiteData>(currentSite))
{
// Do something with the WS.
}

Drastic change? No, not really. But it keeps things clean.

Visual Studio help-launcher rant

2007-09-03T12:34:00Z

Yes, I know I am far from the first to bemoan the atrocious behavior of Visual Studio 2005 when you press the F1 button, even accidently. The first time you do it - or other times, if it deems the contents sufficiently changed for some reason - you are treated to an obnoxious and uncancellable dialog saying Help is updating itself and showing an uninformative neverending progress bar.

Worse yet, this window, despite being non-modal (due to running in a different process, dexplorer.exe) still blocks the calling thread on devenv.exe, preventing me from working for up to 5 minutes(!) at a time. No Abort button, no way to tell it to skip this pointless operation - launching help from VS is simply a giant waste of time.

What I now discovered is that I can't even use the task manager to kill the dexplore.exe process, because Visual Studio actively monitors it and RELAUNCHES it, apparently from scratch, if I try to do so.

So tell me, what program manager decided that this particular feature, launching the Help window in a completely different process, was so amazingly important that it was allowed to take over my Visual Studio completely for whole minute while I just sat there and twiddled my thumbs?

Infuriating.

UPDATE:

Tools -> Customize -> Keyboard -> Show Commands Containing -> Help.F1Help -> Remove.

There. F1 is disabled. Peace is resumed.

Wrong constructor called in COM+: sneaky, sneaky bug

2007-08-30T14:35:25Z

Here's another nasty one that tried to bite me today. Let's say I have the following classes:

public class COMPlusClass : ServicedComponent
{
   public COMPlusClass()
   {
      // Default initialization.
   }

   public COMPlusClass (string data)
   {
      // Parameterized initialization.
   }
}

public class Client
{
    public Client()
    {
       COMPlusClass cpc = new COMPlusClass("I am a client");
    }
}

Which constructor do you think will be called?

Naturally, I wouldn't ask if it was the second one. Much to my surprise, the first constructor was called when I instantiated the COM+ component.

Why is this? Because COM+, due to its COM heritage, requires all components to expose a default, public, parameterless constructor and always initializes through it.

Why didn't I get an error, then? Because I'm writing .NET classes that don't know in advance that they will be instantiated through COM+. If all I know of COMPlusClass came from a COM type library, the second ctor probably wouldb't be exposed. But since I see it as a .NET class, I can believe I am instantiating the parametrized constructor. COM+ probably discards my precious string along the way.

Solution? Add some sort of Initialize method to pass the construction data.

Unmanaged deployment is a true DLL Hell

2007-08-29T23:16:07Z

By a staggering margin, most of my problems integrating C++/CLI code into my C#-based project has been deployment problems. Without fail, every integration or test deployment will be plagued with inexplicable problems. I'll try to list a few, with their causes and (probable) solutions:

1) .NET assemblies are usually very loose in what they'll bind to. If I compiled A.DLL against B.DLL version 1.0.0.0, it will still work if it can only find B.DLL version 1.2.0.0. I don't have to rebuild and reversion everything every time. However, if my C# A.DLL has a reference to my CPPCLI.DLL v1.0.0.0, and I then put CPPCLI.DLL v1.1.0.0, I'll get an exception saying the referenced DLL wasn't found. Annoying.

Solution: If you're changing the version number of a C++/CLI assembly, make sure to recompile any assembly that references it.

2) C++/CLI can be compiled as a pure .NET assembly, just like C# or VB. I don't really see the point in that, unless I'm a C++ coder and refuse to switch syntax. There isn't a great deal of benefit to that over writing in C#, because I can't reference unmanaged code easily. The standard mode, /clr, allows me to mix both managed and unmanaged code. The problem is that a mixed-mode assembly has a dependency on the Visual C++ Runtime libraries. This means that if the machine I am installing on doesn't have it, I'll crash. Furthermore, if I developed my code on a machine running VS2005SP1, my MSVCRT version will be 8.0.50727.762, but on a machine with vanilla .NET2.0 and the corresponding runtimes, I'll just find 8.0.50727.42. Result? An inexplicable "FileNotFoundException", not saying what's missing.

Solution: Make sure your deployment scenario includes installing the relevant MSVC++ Runtime. VS2005 comes with a Merge Module (msm) so you can add it to any MSI project.

3) The usual reason to add C++/CLI code to a C# project is to act as a bridge to an unmanaged API. Usually this API is composed of various DLLs. These DLLs can come in many forms - some are statically linked to their respective runtimes, some link dynamically. Some expect other DLLs in the same directory, others expect them in the PATH. Many times we'll get cryptic Module Load Failed errors or FileLoadFailedExceptions.

One tool we have for this is Filemon and Procmon, SysInternals' wonderful debugging tools. Open them up, add a filter to weed out the noise and see what files receive a FILE_NOT_FOUND error.

Another indispensible tool is the Dependency Walker (depends.exe) that is shipped with Visual Studio (C:\Program Files\Microsoft Visual Studio 8\Common7\Tools\Bin). This tool will show you all the DLLs that our file has a dependency on. First thing to look for is any dependencies highlighted in red, underneath the tree. These are our missing buddies. Ignore anything that has a little hourglass next to it - these are delay-load modules and probably not the source of the problem.

One thing to note when opening our C++/CLI DLLs in Depends is the dependencies on the MSVC++ Runtime. Look for a dependency on "MSVCP80.DLL". You might find instead "MSVCP80D.DLL" - this means that we're bound to the Debug build of the runtime, which probably doesn't exist on our servers. This usually means that we've compiled the project in DEBUG build, rather than RELEASE.

One last indispensible tool is trusty old Reflector. Open our managed A.DLL that contains a reference to CPPCLI.DLL, and we can see what version it was referenced against. This can help us find problems like I mentioned in section 1.

There, that's all I can think of at the moment. Hope it gets some googlejuice and helps someone stuck as I am.

More Tales from the Unmanaged Side - System.String -> char*

2007-08-28T16:08:50Z

Today, I had a very tight deadline to achieve a very simple task: pass a managed .NET string to an API function that expects a null-terminated char*. Trivial, you would expect? Unfortunately it wasn't.

My first though was to do the pinning trick that I mentioned in my last post, but in this case I needed my resulting char* to be null-terminated.

Second thought was to go to the System.Runtime.InteropServices.Marshal class and see what it had for me. I found two contenders:

1) Marshal::StringToBSTR() - this creates a COM-compatible BSTR. I found various tutorials about BSTRs saying that they MIGHT be, under SOME circumstances, compatibles with zero-terminated wide-character strings. Didn't seem to be safe enough.

2) Marshal::StringToHGlobalAuto() - this allocates a block of memory, copies the characters in and even null-terminates it for me. This looked like a winner. Stage one was done - we managed to get an unmanaged string. But can we use it now?

The next problem was that StringToHGlobalAuto returns an IntPtr, and casting it to a char* led to a compilation error. The solution to that is either to cast the IntPtr to a (void*) before casting to (char*), or to do the same action by calling the IntPtr's ToPointer() method. The second option seems neater to those of us who like as few direct casts as possible - I'd rather my conversion was done by a method than by a possibly unsafe casting operation. I'm sure those more concerned with method-call overheads will disagree.

The next problem is that the result of this operation was a single character string - the first character from the expected string. C++ programmers who've struggled with Unicode will quickly spot the problem.

char* strings are null terminated - the first byte containing 00 is the terminator. For Unicode strings as returned by StringToHGlobalAuto, each character takes 2 bytes. If it's a character from the lower reaches of the Unicode spectrum, the second byte, being the high-order byte, will usually be 00, thus terminating the string. There are two options:

1. Instead of char*, use wchar_t* - wide, 2-byte character string, terminated by two null bytes.
2. use StringToHGlobalANSI, which converts the string to standard 8-bit ANSI encoding. This should be used only if we know we can't receive any unicode characters, or (as in my case) when the API we call only acceptts char*. :(

So that's a bit more C++ that haunted and taunted me today. See you next time.