Ok I admit it, I’m a developer and configuring access to SQL Server is not my bag (baby). SQL 2005 had a nice big Surface Area Configuration button than just allowed access from clients, so I ignored what it was doing, pressed it and got on with my work. However, SQL 2008 seems to be have been targeted at me because it no longer has such a backdoor and forced me to find out what I should do. So I thought I’d write it down for others who prefer to search the web rather then read the documentation <oops>,

First off you need to open the SQL Configuration Manager and check your favourite protocol is enabled, for me that would be TCP/IP. Double click that and select the IP Addresses tab. You’ll notice in there a list of possible IP addresses and ports for SQL to listen on. You can, if you maintain your (mine) lazy tendencies simply change the setting from dynamic to static and plug in port 1433. When clients attempt to connect to your server they attempt to use 1433. Now this isn’t supposed to be a good idea (no idea why – you’ll see why later) so stick with dynamic ports. Now this means that SQL will listening on some port but you’ve no idea what as it may change each time the server starts. So you must start the SQL Browser Service, this acts as the go-between and “tells” the client what port to use. So there you are, you should now be off and running. But why not use 1433? I thought the idea was slow those pesky hackers down, but if you have to open the Browser Service then what does that achieve? Something I need to look into, when I have the time, when I have the time, when I have the time…..

It’s still early days for the W3C Widget, but the idea of been able to write a little application that I can run on numerous devices and platforms without requiring any changes is interesting (well I spose you could call that Adobe Air, maybe even my beloved Silverlight at a stretch – but even they requires an additional plug-in). So knowing that in reality they’d be difference I set of downloading various SDKs. However, I hit a number of installations problems all of which I’m sure are down to dodgy installers, beta software and 64bit Windows – not a clever combination I admit. So I grabbed trusty WinMobile and started on that first. The first issues was getting Visual Studio to sync up with the emulators. No chance, there is no project for widgets you have do everything by hand. So here is my very quick guide to get you working;

1. Install Win Mobile 6 SDK refresh
2. Install Win Mobile 6.5 Dev Toolkit – you’ll now have the emulators available to the device manager
3. Create a blank web site
4. Add content – see

http://windowsteamblog.com/blogs/windowsphone/pages/getting_2D00_started_2D00_with_2D00_widgets.aspx

http://msdn.microsoft.com/en-us/library/dd721906.aspx

5. To test I used a great little util http://widgetemulator.codeplex.com/
6. Then to try it out for “real” create a shared folder in the emulator pointing to your .wgt file, and browse to it from the PDA folder browser

My colleague and I ran into a problem today where an old ASP site had problems creating old VB6 components. So as not to forget what to do;

In Win64 the registry is conceptually broken into two versions, one for 64 and one for 32 (or Wow). So when you register a 32bit COM component then it lives under HK_CLASSES_ROOT\Wow6432Node rather than just HK_CLASSES_ROOT. This is important because when we were profiled the registry access would could see that the call to create the object was failing because it couldn’t locate the prog id in CLASSES_ROOT. The reason it was looking there was the web site was running as a 64bit process and therefore was looking in the Wow section. The answer to the problem was hidden away in the Advanced Settings of site’s Application Pool in IIS. By turning on ‘Enable 32bit applications’ the OS was able to redirect the registry requests to the correct location and the object was successfully created.

I thought I’d show what happens when you’re attacked by a fake anti-virus scam…

It starts off by popping up a message (note it says from webpage and not the OS)

Then it looks like Windows Explorer but it’s really still just the browser. Also this is running Win7 and not XP as the fake page tries to look like

Looks realistic though doesn’t? You can see why people have fallen for it. And now for the money…

Yeah I think I’ll say no to that don’t you, thanks for asking.

So be careful out there.

This confused me for a bit, they’ve moved the Network DTC Access dialog from the MSDTC tab to it’s own node…

Select properties on the above node…

Silverlight & Blend try and encourage you to separate styles and structure in much the same way as you should with HTML and CSS. However, Blend can be confusing as it will offer up some properties to be changed but “hide” others. One example of this is the seemingly simple task of changing the colour of the text in a button. You’d be forgiven for thinking you can select the button and directly edit the foreground colour since the background is available. You must ignore this temptation, if you don’t attempt to make style changes directly to the structure (control) then you’ll avoid a lot of confusion. I’ve created a little tutorial to show one way of solving this;

1. Create a new project in Blend and accept the defaults.
   
2. Add a button
   
3. Select the button, hint using the control tree is often more reliable, right-click and choose Edit Templatate->Edit a Copy. To promote separation I recommend saving the style to the Application. You should give the style a good name, but I’ll be naughty and leave it at ButtonStyle1
   
4. You’ll now find yourself in the Template for the button. Ignore this and return the MainPage.xaml (there is a quicker way but lets keep things simple). Now you want to change the colour of the button, so you need to edit the buttons style. Select the Resources tab and click the button to edit ButtonStyle1
   
5. Now switch back to the Properties tab and you can change the Foreground (remember to drag the little colour select from the bottom left of the selector).
   
6. All done.

So the “take home” from this is don’t make style changes directly to your controls always look at changing the separate style xaml, not only will you have better separation but you’ll avoid a lot of frustration when trying to find the property you want to change.

Had some fun today with code signing some macro's in Excel. Applying a code signing certificate is very easy, simply go to the visual basic editor, tools->Signing and you're away. The problem is creating the correct type of certificate in the first place.

My sys admins provided with a p7b certificate. So I installed that, but it didn't show in VBs available certificates. So I thought I'd better try and understand what was going on. In turns out that I need a pfx certificate and a p7b is just part of formula for creating such a beast. You need the private key used to create the original certificate together with the p7b;

pvk2pfx -pvk privateKey.pvk -spc codeSignCert.p7b -pfx actualCodeSign.pfx -po myPassword -f

That will challenge you for the password used to create the original certificate but will produce required pfx file. Now just install that and it should be available for signing

Vista on Parallels 3 was good, Vista on Parallels 4 was terrible. So I wasn't too bothered in ditching my Vista VM and installing Windows 7, even though it's only marked as 'experimental'. Well so far it's been as good as P3, so I'm very happy with it. Don't know where the blame falls for P4+Vista but P4+Win7 is worth having.

I’ve been working on a Silverlight project that where the SL application is used within an authenticated ASP.net site. During my testing I found a problem where using Silverlight 3’s Out-Of-Browser feature seem to lose the session token between calls to the site, i.e. I could logon but the next call would fail as if the user had not logged on. After a couple of Twitter conversations it became apparent that it should work. So I decided to take my testing back to basics, so first off can a Silverlight application use ASP session state?

1. Create a basic Silverlight application – create a Silverlight application with a web project to host it

2. Create a basic web service – with the web project selected add a new Silverlight WCF service, called SessionTest.svc
   

3. Implement some very simple interactions with the Session State
   

   [ServiceContract(Namespace = "")]

       [AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Allowed)]

       public class SessionTest

       {

           [OperationContract]

           public void SetState(string value)

           {

               // Add your operation implementation here

               HttpContext.Current.Session["TestState"] = value;

               return;

           }

    

           [OperationContract]

           public string GetState()

           {

               // Add your operation implementation here

               return (string)HttpContext.Current.Session["TestState"];

           }

       }

4. Add a Service Reference from your Silverlight application to your service, add appropriate using statements to your code-behind.

5. Create some simple controls in your Silverlight application
   
   

   <StackPanel>

       <StackPanel Orientation="Horizontal">

           <Button x:Name="ButtonGetState"  Content="Get State" Click="ButtonGetState_Click" Width="60" ></Button>

           <TextBlock x:Name="TextBlockCurrentState" Width="100"></TextBlock>               

       </StackPanel>

       <StackPanel Orientation="Horizontal">

           <TextBox x:Name="TextBoxNewState" Text="" Width="100"></TextBox>

           <Button x:Name="ButtonSetState" Content="Set State" Click="ButtonSetState_Click" Width="60"></Button>

       </StackPanel>

   </StackPanel>

6. Add code to the Silverlight application to communicate with the Service
   
   

   private void ButtonGetState_Click(object sender, RoutedEventArgs e)

           {

               SessionTestClient client = new SessionTestClient();

               client.GetStateCompleted += (object completedSender, GetStateCompletedEventArgs completedE) =>

                   {

                       if (completedE.Error == null)

                       {

                           TextBlockCurrentState.Text = completedE.Result;

                       }

                   };

               client.GetStateAsync();

           }

    

           private void ButtonSetState_Click(object sender, RoutedEventArgs e)

           {

               SessionTestClient client = new SessionTestClient();

               client.SetStateCompleted += (object completedSender, AsyncCompletedEventArgs completedE) =>

                   {

                       if (completedE.Error == null)

                       {

                           TextBlockCurrentState.Text = "";

                       }

                   };

               client.SetStateAsync(TextBoxNewState.Text);

           }

7. Run the code, you should see that after you set a value you can retrieve the same value.

So we now know for sure that we can communicate with ASP.net and share the session state with the page. If you make the Silverlight application OOB (select project properties and check the OOB box) you’ll see that it continues to work without any problems. So this is good news, all I have to do now is track down why it isn’t working in my real application.