Codebureau - Matt Simner

I recently (November) bought a cheapy digital camera for my 5 yr old's birthday.  Yes - I know, a 5 year old with a digital camera - where will it stop.  Anyway...

The model was a Samsung S630 (cost $97 AUS), and you'd be forgiven for thinking it had a reasonable manual given it's a budget camera.  A quick look and you realise that there's about 4 pages X lots of languages.

I'd bought a Canon Ixus 2 a few years ago and apart from it having a few plastic bits that proved to be a bit fragile it's served me very well with its rechargeable battery.  We quickly found that the Samsung had 'awful' battery life, and found that this was the general experience of most people with 'cheaper' digital cameras that take AA batteries.  I bought a few Ni-MH batteries and a charger and thought, well if I'm going to get through so many batteries (as my child had the camera permanently strapped to her wrist) they're going to be rechargeable!

No beef with the rechargeables, and we quickly got to the point where we couldn't put 'any' battery in without it immediately showing 'Low Battery' and shutting the camera down.  One obviously smells a rat at this point.  I was all ready to take the thing back to the shop then (after realising I'd misplaced the receipt ) decided to have a quick look for info on this model and its spectacularly poor battery life.

A quick google found reviews on Amazon - so I started to read.  My heart sank as I read review after review quoting the same issues I'd found - but also the lack of support they then had from the supplier leaving them pretty much in the cold - grreeat I thought to myself.  I was still interested however, because there were quite a number of positive reviews also.  Now knowing software like I do I thought what are the odds of a systematic problem as severe as not being able to turn the thing on! being present in about 2 thirds of cameras (about the ratio of bad to good reviews).  I read a couple of 'responses' to the bad reviews and one in particular that had some very simple but vital information that was missing from the manual.  

I charged up my batteries as much as I could then (after the camera actually switched on - but showing 'red' battery life) I found the menu item to switch to Ni-MH batteries, and hey presto I'd suddenly got 3 'bars' wahey!

So the moral of the story is that Google is now 'also' your friend for household appliances with increasingly shoddy manuals.  You may also of course be like me and have Techno-Joy (from the wise words of Eddie Izzard), and have just disregarded the manual anyway!

We want to cut down on email traffic and storage so we're suppressing some automated stuff and moving the remainder into public folders that will have a cycling deletion of items over a certain age (as we don't need to keep the info indefinitely).  The problem is that it's a few clicks to access the right folder in Outlook (the enterprise folder structure is quite large).

A little known feature of Outlook is its ability to give access to almost anything (including public folders) from within your mailbox just by creating 'shortcut' folders.

1. Create a new folder within your mailbox
2. Right-click - Properties and go to the 'Home Page' tab.
3. Enter an appropriate URI - this could be a file reference, web page, or any other location, e.g. Outlook Public Folder.  
   
   Ensure that you tick the 'show home page by default for this folder', as this is what displays the item
   
   An easy way to get the address of an outlook item is navigate to it - e.g. a Public Folder and use the 'Web' toolbar to retrieve the address (View-->Toolbars-->Web):
   
   Copy the address and away you go

It's important to note that this is really just Outlook acting like a pseudo browser so you won't be able to navigate down a structure of public folders.  It's still an Outlook folder you've created and it expects you're storing posts or contacts (whatever you specified when you created it), not folders.  Still a pretty useful feature though. 

Another use might be if you hive off all your email from a supplier into a sub folders, the home page of the 'parent' folder could be their web site.  A different way to use favourites and drop your click-count?! 

I thought I was being a bit clever some time back when I wrote a little .NET wrapper for performance counters, largely for the reason of allowing clients to happily work with counters that weren't installed on their machine.  The default behaviour is an exception when you attempt to use a non-existant counter.

This was all good until deployment to servers and clients with 'real' non-admin users.  I then read that only administrators and power users could increment counters (awww!).

I just found this MS article that explains how to get around this as the 'permissions' are simply based on registry permissions for HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Perflib.

To set the permissions,

1. Open Regedit to that key
2. Right-click, select 'Permissions...'
3. Add your user's groups or specific name with 'Full Control'

I can now actually implement the solution (1 year on!)

This is obviously what happens when you get really serious about technology like Mr Hanselman and want to work remotely...

There's a fairly major annoyance about VS2005 and the fact that when you create 'New Class' it effectively creates the class as private.  This article explains how to change it...

http://mark.michaelis.net/Blog/ChangingTheDefaultItemTemplatesInVisualStudio2005.aspx

I've been told and have read many times that it's not possible to run Microsoft CRM 3.0 under .NET 2.0.  Well, I guess 'not possible' could just mean 'not supported'.  All of our code base is now .NET 2.0 and I was loathed to maintain .NET 1.1 versions of our framework libraries jsut for a couple of calls out of CRM. 

I had previously found this article on extending CRM with ASP.NET 2.0 apps, but needed to create a Workflow component to call into our internal systems and found that this obviously didn't work because (all of) CRM runs under .NET 1.1.

A bit of 'give it a try' later and I can reveal that it is indeed possible to successfully run CRM 3.0 in a .NET 2.0 process, and also use .NET 2.0 assemblies with Workflow.  I'll leave it up to the reader to decide whether this is a good idea that they'd actually want to implement!  The process isn't too onerous so wouldn't take long to roll back if you encountered problems.

If you're still up for giving it a try then you'll need to alter the ASP.NET properties for the CRM Web Site and Service ...

Make sure you've set up separate app pools (see below), as one will run all your ASP.NET 1.1 apps, and the other will run the .NET 2.0 apps.  You can't run a mixture of runtimes within the same app pool.

Change the Microsoft CRM v3.0 site's root folder, AND the MSCRMServices virtual folder as below to use .NET 2.0 (and make sure they're configured to be in your .NET 2.0 app pool).

Now to ensure Workflow can use .NET 2.0 you'll need to add a .NET config file to force the Workflow Service to run in the .NET 2.0 runtime.

Stop the "Microsoft CRM Workflow Service", then Add a file as below in the CRM Workflow binary folder.

The contents of the file should be as follows:

<configuration>
  <startup>
    <supportedRuntime version="v2.0.50727" />
  </startup>
</configuration>

Restart the Workflow Service (and probably do another IISReset for good measure), and you should find everything comes up fine, and you'll be able to configure Workflow as per normal but now with .NET 2.0 assemblies.  I'm not too familiar with 'where' callouts run, but I'd presume that the same principles should apply and .NET 2 assemblies should work OK.

This procedure is obviously not supported by Microsoft so you use at your own risk, but I've had no problems so far....

What next - COBOLUnit?  Haven't tried this yet, but this could be a good tool for 'self-diagnostic' tests on Servers...

http://www.codeplex.com/psexpect/Wiki/View.aspx?title=User%20Guide&referringTitle=Home

Like many people I'd mistakenly thought that xxx.Parse was the only way to validate types like ints and DateTimes.  This kindof 'was' the case in .NET 1.1, but numeric data could be validated with Double.TryParse then converted to the correct type.

In .NET 2.0 you can happily use the TryParse method on pretty much all the types you'd want to validate - without the nasty overhead of catching an exception.  This post goes into a bit more detail, and links to a tool to benchmark the results for yourself.

I'll be on the lookout to convert whereever I find int.Parse, as it's pretty rare you 'actually' want an exception to be thrown...