Janne Mattila's blog : .NET General

Web Services and namespaces (or WCF?)

jannemattila — Wed, 15 Oct 2008 10:27:28 GMT

You might have encountered following situation:
1. You have created class library “MyLibrary” and it contains following class:

namespace MyLibrary
{
  public class Employee
  {
    public string FirstName;
    public string LastName;
  }
}

2. You have created Web Service “MyWeb” using following VS template:

- It references “MyLibrary”
- It contains following method:

public class MyWeb : System.Web.Services.WebService
{
  [WebMethod]
  public void AddNewEmployee(MyLibrary.Employee employee)
  {
    // TODO: implement
  }
}

3. Finally you create Windows Forms application “My Win App”:
- You “Add Web Reference” to “MyWeb” and you name it “WebServices”
- You write following code to use that web service:

WebServices.Employee employee = new WebServices.Employee();
employee.FirstName = "John";
employee.LastName = "Doe";
WebServices.MyWeb myWeb = new WebServices.MyWeb();
myWeb.AddNewEmployee(employee);

4. You run your application and all is fine.
5. Later you notice that you need to add reference to your “MyLibrary” into your “My Win App”
(There could be many reasons for this. For example you want to use same business logic that web service uses etc.)
6. You add following code to you “My Win App”:

1
2
3

MyLibrary.Employee employee2 = new MyLibrary.Employee();
MyLibrary.EmployeeManager employeeManager = new MyLibrary.EmployeeManager();
employeeManager.AddNewEmployee(employee2);

7. Code works fine but then you notice that you actually have the same class from two different namespaces. What if you try to mix and match them (and sometimes you just have to do that)? Let’s see what happens:

1
2
3

WebServices.Employee employee = new WebServices.Employee();
MyLibrary.EmployeeManager employeeManager = new MyLibrary.EmployeeManager();
employeeManager.AddNewEmployee(employee);

8. When you try to compile your application and you’ll receive following error:
Error    11    The best overloaded method match for 'MyLibrary.EmployeeManager.AddNewEmployee(MyLibrary.Employee)' has some invalid arguments    C:\<path>\MyWinApp\MainForm.cs    41    1    MyWinApp
Error    12    Argument '1': cannot convert from 'MyWinApp.WebServices.Employee' to 'MyLibrary.Employee'    C:\<path>\MyWinApp\MainForm.cs    41    32    MyWinApp

9. You open up the generated proxy code:

10. You locate the code where Employee is defined and comment that part. And then you compile again with following results:
Error    11    The type or namespace name 'Employee' could not be found (are you missing a using directive or an assembly reference?)    C:\<path>\MyWinApp\Web References\WebServices\Reference.cs    82    36    MyWinApp

11. You fix that by resolving the missing type:

12. You compile and you’re happy right (obviously you need to modify also all WebServices.Employee types to MyLibrary.Employee types)?

Well you might be happy since now your code works... BUT you have manually edited generated file which will be re-generated every time you do “Update Web Reference” from Visual Studio and you’ll lose you modifications. And that’s not nice.

If this would be question for me I would give you following answer (you might find different opinions on this one): Go to the WCF route instead :-) If Windows Communication Foundation (WCF) is something new to you I think you should check these out and find more information on the web: Overview of WCF from Wikipedia and Windows Communication Foundation home on MSDN.

I’m going to run through this same example with WCF way and then we can (hopefully) see why it fits like good glove.

1. Create new WCF project called “MyWcf” using following VS template:

2. Add reference to “MyLibrary”
3. Delete IService1.cs and Service1.svc from your newly created project.
4. Add new item “MyWcfService.svc” (using WCF Service template)
5. Modify “IMyWcfService.cs” file:

using System.ServiceModel;
using MyLibrary;

namespace MyWcf
{
  [ServiceContract]
  public interface IMyWcfService
  {
    [OperationContract]
    void AddNewEmployee(Employee employee);
  }
}

6. Modify “MyWcfService.cs” file:

using System;
using MyLibrary;

namespace MyWcf
{
  public class MyWcfService : IMyWcfService
  {
    public void AddNewEmployee(Employee employee)
    {
      // TODO: implement
    }
  }
}

7. Open up “web.config” and modify the system.serviceModel section as follows:

<system.serviceModel>
 <services>
  <service behaviorConfiguration="MyWcf.MyWcfServiceBehavior" name="MyWcf.MyWcfService">
   <endpoint address="" binding="basicHttpBinding" contract="MyWcf.IMyWcfService">
    <identity>
     <dns value="localhost" />
    </identity>
   </endpoint>
   <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" />
  </service>
 </services>
 <behaviors>
  <serviceBehaviors>
   <behavior name="MyWcf.MyWcfServiceBehavior">
    <serviceMetadata httpGetEnabled="true" />
    <serviceDebug includeExceptionDetailInFaults="false" />
   </behavior>
  </serviceBehaviors>
 </behaviors>
</system.serviceModel>

(you might notice that most important part is the binding what I have changed to be basicHttpBinding)

8. Go back to your “My Win App” project.
- Remove “WebServices” web references
- Add new “Service Reference” to your newly created WCF Service and name it “WcfServices”
- Verify that you have “Reuse types in referenced assemblies” checked in settings (you can see them if you click Advanced... button from the “Add Service Reference” dialog):

9. Modify your code to use this new service:

MyLibrary.Employee employee = new Employee();
employee.FirstName = "John";
employee.LastName = "Doe";
WcfServices.MyWcfServiceClient myWcf = new MyWinApp.WcfServices.MyWcfServiceClient();
myWcf.AddNewEmployee(employee);

10. Enjoy one of the benefits of WCF :-)

This is just one of the many benefits that WCF over the “good old ASP.NET Web Services”. So if you’re interested then you should start looking more information on the web.

Anyways... Happy hacking!

J

Maximize the use of CPU with parallel extensions (+ some WPF stuff)

jannemattila — Tue, 26 Aug 2008 22:03:00 GMT

Since this is my 40th post to this blog I decided to go back to square one… or post one actually :-) I’m going to create Windows Presentation Foundation (WPF) application that solves the Knight’s Tour puzzle. I actually didn’t know about this puzzle before I bought book called Puzzles for Programmers and Pros. That book had interesting puzzle that lead in to this post. So here we go!

I said that I’m going to create WPF application for my UI. You might ask why not the “good old” Windows Forms application...? Well for these simple reasons:

1. I don’t like to write code to OnPaint / MainForm_Paint methods.
2. I wanted to define my user interface and then just say in code “hey knight go there” and it should just draw the UI with the knight in the correct position. But the defined UI must be also scalable.
3. WPF doesn’t have same barriers than Windows Forms does => It’s the face of future applications!

I don’t probably have to explain my reason #1 for you if you have experienced the same that I have :-) You’ll end up writing the UI code a lot and that’s not what you’re trying to do. You’re trying to solve puzzle and you are suddenly focusing for the UI code. That’s wrong approach. Therefore reason #2 goes hand-in-hand with #1.

So let’s look the the UI of the running application:

It’s the view of the classic chess board and I decided to take shortcut when creating the knight. I decided to use gray circle instead (or ellipse actually) :-) And for the layout management I just took the easy approach by using Grid and defining Columns and Rows. Here is the XAML for the UI:

<Window x:Class="Window1"
   xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
   xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
   Title="Knight's Tour" MinHeight="100" MinWidth="100" 
     Width="300" Height="300" Loaded="Window_Loaded">
  <Grid x:Name="Board">
    
    <Grid.ColumnDefinitions>
      <ColumnDefinition />
      <ColumnDefinition />
      <ColumnDefinition />
      <ColumnDefinition />
      <ColumnDefinition />
      <ColumnDefinition />
      <ColumnDefinition />
      <ColumnDefinition />
    </Grid.ColumnDefinitions>
    <Grid.RowDefinitions>
      <RowDefinition />
      <RowDefinition />
      <RowDefinition />
      <RowDefinition />
      <RowDefinition />
      <RowDefinition />
      <RowDefinition />
      <RowDefinition />
    </Grid.RowDefinitions>

    <Ellipse x:Name="Knight" Fill="Gray" Panel.ZIndex="1"
         Grid.Column="{Binding Path=KnightX}" 
         Grid.Row="{Binding Path=KnightY}" />
    
    <Rectangle x:Name="A8" Fill="White" />
    <Rectangle x:Name="B8" Grid.Column="1" />
    <!-- Etc... -->
  </Grid>
</Window>

You probably noticed the interesting part of the XAML... and that’s the lines 30 and 31 where Binding is defined. It means that these values coming from the public properties of the DataContext. So let’s look at the code behind that XAML and let’s discuss the binding little bit more:

using System;
using System.ComponentModel;
using System.Diagnostics;
using System.Windows;
using System.Windows.Media;
using System.Windows.Shapes;

public partial class Window1 : Window, INotifyPropertyChanged
{
  private int knightX = 0;
  public int KnightX
  {
    get { return knightX; }
    set
    {
      knightX = value;
      NotifyPropertyChanged("KnightX");
    }
  }

  private int knightY = 0;
  public int KnightY
  {
    get { return knightY; }
    set
    {
      knightY = value;
      NotifyPropertyChanged("KnightY");
    }
  }

  private void Window_Loaded(object sender, RoutedEventArgs e)
  {
    Knight.DataContext = this;
    // Now moving the Knight is easy!
    KnightX = 3;
    KnightY = 3;
  }

  public event PropertyChangedEventHandler PropertyChanged;
  private void NotifyPropertyChanged(String info)
  {
    if (PropertyChanged != null)
    {
      PropertyChanged(this, new PropertyChangedEventArgs(info));
    }
  }
  //...

You might already noticed that my window also implements INotyfyPropertyChanged interface. And my two properties actually call NotifyPropertyChanged method when they are changed. So what’s this all about? Well if you don’t do this your values will be updated for the first time and after that they don’t actually get “bubbled” up to the ellipse anymore... unless you implement the notify mechanisms yourself. This is quite important and you should probably read more information about it on MSDN.

For the actual solving part I just used classic “old recursion” to solve the puzzle. And this is the part where we finally are going to the title of my post...

Classic one worker thread approach gives “fairly easy to implement but sub-optimal” solution. And you might ask why? And to answer this question I’m going so show you picture of task manager:

This picture was taken when my solver was running in “full speed ahead” –mode. And guess what... I’m not impressed! I’m actually just using single CPU (see the third box where green line has reached the roof)!!! So my worker thread approach is far from optimal resource usage.

Okay... What can I do then? I could do multiple threads and handle them manually but that’s again writing a lot of code that doesn’t have anything to do with the actual solving!? So if I would chosen Windows Forms + manual handling of multiple threads I would have a lot of code and just small fraction of that would actually do work that I was originally planning to do.

This is where Parallel Extensions (download) comes into the game! It’s additional library (System.Threading.dll) sitting on top of .NET Framework 3.5 and it’s currently in CTP phase. But I still highly recommend you to check it out if you want easily get more horse power to your algorithms.

I analyzed my code and noticed part where I could do things differently:

// My code was this:
foreach (int location in startLocations)
{
  // Calculations here!
}

// And I changed it to this:
Parallel.ForEach<int>(startLocations, (location) =>
{
  // Calculations here!
});

So I changed code in line 2 to be the code at line 8. What was the result at the task manager then:

Well I believe that I managed to get better use of the available horse power :-) It shows of course in the results:
“foreach”: ~50 solved solutions in ~5 minutes
”Parallel.ForEach”: ~450 solved solutions in < 5 minutes

To summarize... I just changed 1 line of code and I was able to get unbelievable results from it! So if you’re doing something similar then I recommend checking out the parallel extensions first before doing “own custom solution” for that.

I originally thought that I would go little bit deeper into the details of my solver but this post ended up too long even without it so maybe I’ll pass this time... But I’ll include video clip that shows the UI of the application when it’s solving.

Anyways... Happy hacking!

J

P.S. I’m also interested in F# and I’m probably going to do something fun with that too.

Transferring attachment file from Web Service to InfoPath

jannemattila — Thu, 08 Feb 2007 09:21:27 GMT

I previously posted about InfoPath and Web Service data connections. Back then I didn't mention that you could use the same method to transfer InfoPath attachments as well. It's actually pretty straightforward thing. All you need to do at the web service is wrap up you existing file data to InfoPath file attachment format and return it as BASE64 encoded. It sounds easy and it really is. Well enough talking... let's checkout the code!

First we need method that creates InfoPath attachment from byte array. It could be something like this:

 1  static public String CreateInfoPathAttachment(String fileName, byte[] fileData)
 2  {
 3      // This memory stream for InfoPath attachment buffer before Base64 encoding.
 4      using (MemoryStream ms = new MemoryStream())
 5      {
 6          uint fileNameLength = (uint)fileName.Length + 1;
 7          byte[] fileNameBytes = Encoding.Unicode.GetBytes(fileName);
 8
 9          using (BinaryWriter bw = new BinaryWriter(ms))
10          {
11              // Write the InfoPath attachment signature. 
12              bw.Write(new byte[] { 0xC7, 0x49, 0x46, 0x41 });
13
14              // Write the default header information.
15              bw.Write((uint)0x14); // size
16              bw.Write((uint)0x01); // version
17              bw.Write((uint)0x00); // reserved
18
19              // Write the file size.
20              bw.Write((uint)fileData.Length);
21  
22              // Write the size of the file name.
23              bw.Write((uint)fileNameLength);
24  
25              // Write the file name (Unicode encoded).
26              bw.Write(fileNameBytes);
27  
28              // Write the file name terminator. This is two nulls in Unicode.
29              bw.Write(new byte[] { 0, 0 });
30              bw.Write(fileData);
31          }
32          return Convert.ToBase64String(ms.ToArray());
33      }
34  }

This code has been "copy-pasted" mainly from this source. However there is unnecessary code (=my opinion) so I have changed it a little bit. I prefer using the existing ToBase64String method (unlike in original code sample).

Now all you need to do at you web service is to pass filename and data to the method and it creates BASE64 encoded string that can be returned to the InfoPath.

1  ...
2  String fileName;
3  DocumentContainer myDocument;
4  ...
5  byte[] fileData = File.ReadAllBytes(fileName);
6  myDocument.Size = fileData.Length;
7  myDocument.Document = CreateInfoPathAttachment(fileName, fileData);
8  return myDocument;

In my example I use similar approach as in my previous example. I have Document struct that has (in this case) at least to fields: size and document. And in InfoPath I could map those fields exactly as I explained in my earlier post. Now you just map Document field to your InfoPath attachment and that's it:

And what makes this really nice... it works also with Forms Services as well! Of course this idea could be also otherway around... so you could sent file from InfoPath to web service using the same underlying idea. In that case you should only parse the InfoPath attachment so that you get the original filename and filedata. Read more about this case in here.

Anyways... Happy hacking!

J