Discovering coding pearls

I tried running VS2008's profiler and ran into the following problem: VS prompted me to login as admin and then run the profiler (even though I was already logged in). And it ultimately exited with the following error in the output window.

Error VSP1398 : The monitor was unable to install the VS performance driver.  The system cannot find the file specified. Consider using the /Admin: Driver,Install option of VSPerfCmd from an elevated environment.  Profiling cannot continue.
Error VSP1341 : Could not start logging engine.  Shutting down.
Profiler exited
PRF0010: Launch Aborted - Unable to start vsperfmon.exe

Strangest thing is that this worked for me a year back without any problems. But that's when I was using VS 2005. So, I started scouring for a solution to this problem. I saw a couple of posts about this issue, and most of them were talking about hacky workarounds, till I found the correct answer.

Since there are not a lot of posts about how to fix this problem quickly and easily, I'll just add one here :)

Basically all you need to do is install vs_profiler.exe from your VS 2008 DVD. You can either search your DVD for the executable, or go down to VSTS\Standalone Profiler\x86\ and simply double click on vs_profiler.exe to install.

That's it. Now you can profile as much as you want.

PS - paths in the DVD may vary depending upon the flavor of VS and your system architecture (x86 or x64)

I have a Windows service that acts as a cache server and is implemented using WCF. This service mainly returns a stream of data dictionaries to it's clients. Recently there was a request for me to make this service more "debuggable". One of the things that was in the TODO list was: be able to query the cache service directly for specific data.

After a lot of thought I decided to expose a REST endpoint to do this job. And belive it or not, it was super easy to do that. And so, I dedicate this blog post about the task.

My existing service was a singleton and implemented an interface such as ICacheService interface. I simply added a new interface called ICacheLookup interface with a method like GetCustomer(int customerId).

   1: [ServiceContract(Namespace = "http://MyCompany.CacheServiceLookup")]

   2: public interface ICacheLookup

   3: {

   4:     [OperationContract()]

   5:     [WebGet(UriTemplate="GetCustomer?customerId={customerId}", ResponseFormat=WebMessageFormat.Xml)]

   6:     Customer GetCustomer(int customerId);

   7: }

Next for implementation of this method, I used my singleton CacheService implementation and extracted the customer Id from it.

   1: public class CacheLookup : ICacheLookup

   2: {

   3:     public Customer GetCustomer(int customerId)

   4:     {

   5:         Customer customer = null;

   6:         CacheService.Instance.CustomersCache.FullEntities.TryGetValue(customerId, out customer);

   7:         return customer;

   8:     }

   9: }

After this, all that was left was setting up the configuration endpoint and the rest service startup.

   1: <services>

   2:   <service behaviorConfiguration="ServiceBehavior" name="MyCompany.CacheService">

   3:     <endpoint address="net.tcp://localhost:2000/CacheService"

   4:       binding="netTcpBinding" bindingConfiguration="TcpBinding" name="TCP"

   5:       contract="MyCompany.ICacheService" />

   6:   </service>

   7:   <service behaviorConfiguration="ServiceBehavior" name="MyCompany.CacheLookup">

   8:     <endpoint address="http://localhost:2001/CacheService"

   9:       binding="webHttpBinding" bindingConfiguration="WebBinding" name="Rest"

  10:       contract="MyCompany.ICacheLookup" />

  11:   </service>

  12: </services>

Starting the REST service in the ServiceHost:

   1: private static ServiceHost service = null;

   2: private static System.ServiceModel.Web.WebServiceHost webHost = null; 

   3:  

   4: public static void StartService()

   5: {

   6:     Uri baseAddress = new Uri(ConfigurationManager.AppSettings["BaseAddress"]);

   7:     CacheService serviceInstance = CacheService.Instance;

   8:     CacheServiceHost.service = new ServiceHost(serviceInstance, baseAddress);

   9:     CacheServiceHost.service.Open();

  10:  

  11:     CacheServiceHost.webHost = new System.ServiceModel.Web.WebServiceHost(typeof(CacheLookup), baseAddress);

  12:     CacheServiceHost.webHost.Open();

  13: }

No changes were needed for deployment, the REST endpoint simply worked and was accessible using the following url:

http://localhost:2001/CacheService/GetCustomer?customerId=2000

That's all, and it was super easy to get xml serialized data out of the service without much ado. Since then I've become a great fan of REST and declarative programming model : )

I recently had to deal with this issue in which I had created a unit test project with references to all the right Visual Studio quality dlls, and a well formed unit test class with all the pretty [TestClass] and [Test] attributes, but for some reason, none of the tests would show up in the test view.

The fix was: Open up the test project in notepad and add the following line in PropertyGroup element:
    <ProjectTypeGuids>{3AC096D0-A1C2-E12C-1390-A8335801FDAB};{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}</ProjectTypeGuids>

And Walla all tests started showing up in my test list. 

Please note: You'd run into this problem only if you didn't create the unit test project in the kosher way to begin with. Visual Studio takes care of setting the appropiate project type guids if you use it's create test project template.

I'm talking about client side async calls -- i.e. when you use svcutil /a to generate async methods for your WCF service. This is usually rare, but happened to me yesterday -- I was getting nulls back in the EndResponse. I tried a lot of things -- dug up a lot of documentation on how WCF does async under the covers, reformed my responses, tried changes to asyncstate etc; in short spent a lot of time. But the fix was --- had to update the proxy -- that magically started returning entities and got rid of the null refs.

Sometimes the simplest problems take the most evil form.

So, wanted to share my thoughts just incase someone has a similar problem 

I got to use WCF callbacks recently and realized some of it's gotchas, which are listed here:

1. Callbacks requires communication over duplex channel
2. Requires all clients to implement the callback interface, exposed by the service
3. BasicHttpBinding & WSHttpBinding don't support callbacks -- use their Dual versions instead
4. Streaming data not supported by callbacks -- streaming is not reliable and Callbacks require reliable messaging
5. Requires reliable messaging
6. If the service restarts, callbacks are not possible until the client makes a service connection again & subscribes itself for callbacks.

If you'd like to know more about how to setup WCF callbacks etc use this link: http://msdn2.microsoft.com/en-us/magazine/cc163537.aspx

Enjoy!

 ---Ads-by-Microsoft---

Just to be clear, there are 5 types of a SQL joins:

1. Cross-join or Cartesian Product - Joins all rows from one relation with rows from the other relation
2. Inner join - Joins only those rows that have same data in the common attributes of the two relations
3. Outer join - Joins rows in two relations that have same data in the common attributes, and for all the remaining rows (that couldn't be joined) adds NULLs to the attribute values
4. Left outer join - Joins all rows in the left relation either with rows in the right relation (when they have same values for common attributes) or with NULLs
5. Right outer join - Joins all rows in the right relation either with rows in the left relation (when they have same values for common attributes) or with NULLs.

Just rolling it out, because some of us tend to confuse between a cross-join and an outer join and so forth.

Keep joining.

PS: Count the number of times I've called out the word "Join" or it's extensions in this blog : )

Ads-by-Microsoft

If you install Visual studio 2008 while the 2005 version exists, and you have a website project that uses ajax, you're bound to run into the following issue:

You'll see an error saying: "Ambiguous reference of System.UI.Web.Extensions.dll found" . And you probably have a reference on your aspx page that says:
<%@ Register Assembly="System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" Namespace="System.Web.UI" TagPrefix="asp" %>

There are a couple of things that you need to do to fix this:
1. Remove the above mentioned line from your aspx page.
2. Go to the property pages of your website project and remove the 3.5 references to System.UI.Web.Extensions and Design.
3. Rebuild your website and solution.

If removing the line gives you an error say <asp:ScriptManager> tag is not defined, then you'll need to add the following line back in:
<%@ Register Assembly="System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"    Namespace="System.Web.UI" TagPrefix="asp" %>

Hope that helps.

Ads-by-Microsoft

I am back from a long & happy vacation and starting to write to my blog again. I was recently asked how can one make sure that a WCF proxy can work with different clients and here was my answer to them:
1. Keep your interface clean and simple. Don't push in too many Dictionary<> or other complex object types.
2. Try out your service with atleast 4 client types: 1. WCF client, 2. Asmx client, 3. Java client, 4. Php client.

How to make non-WCF client types work with a WCF service?

1. WCF with ASMX client

Convert wsdl into a typed proxy using wsdl.exe: wsdl.exe /urlkey:"MyAPIUrl" /n:"My.Api.Asmx" http://localhost:8080/MyAPI/Service.svc?wsdl /out:MyApi_asmx_proxy.cs. WCF works with asmx as it is. So, no changes would be needed.

2. WCF with Java client

For Java clients, you'll need to convert wsdl into Java proxy classes. You can use the following tool for this purpose axis-wsdl2Java tool. Download axis from this location: http://www.apache.org/dyn/closer.cgi/ws/axis/1_4/. Wsdl2Java takes your wsdl url and generates Java proxy files for your client.

If you get an error like this:

[axis-wsdl2java] java.io.IOException: Emitter failure.  There is an undefined binding (MyApi) in the WSDL document http://localhost:8888/MyAPI/service.svc?wsdl.

[axis-wsdl2java] Hint: make sure <port binding=".."> is fully qualified.

Then you're probably missing the binding element in your wsdl. Go through the wsdl and make sure that you have the following elements: types, services, porttype, binding, message. Binding element could be missing if you have two endpoints under the same service element in app.config. So instead of having something like this:

<services>
<service ... >
<endpoint..1... />
<endpoint..2.../>
</service>
</services>

replace it with this:

<services>
<service..1..>
<endpoint..1../>
</service>
<service..2..>
<endpoint..2../>
</service>

Once you have a successful wsdl2Java conversion, then you can just start coding your client. Please note that you may not necessarily see the above error.

3. WCF with PHP client

PHP uses the wsdl url. You can use $client = new SoapClient($wsdlurl); And start coding the php client.

References:

1. http://msdn2.microsoft.com/en-us/library/ms751433.aspx 

2. http://www.w3schools.com/wsdl/wsdl_binding.asp

---Ads-by-Microsoft---

I tried researching this area over the net, but couldn't find a whole lot. So, here's my blog about it and since this is my very first blog, I'd like to say "Hello World!"

What does it mean to use ChannelFactory?

When you share a common service contract dll between the client and the server, you'll be using the ChannelFactory class. The idea is to package the service contract interface and your entities in a library, that would be implemented by the service and used by the client.

So if you have a contract such as this in Contract.dll:

 public interface IHelloWorld{

string SayHello(int numTimes);

}

You'd use the ChannelFactory class as follows in the client:

using Contract; 

ChannelFactory<IHelloWorld> channel = new ChannelFactory<IHelloWorld>("tcp"); //Binding name

When to use a proxy?

We use proxy in WCF to be able to share the service contract and/or entities with the client. If the client to your service is external to the system, such as API, it makes sense to use a proxy, because it makes sharing the contract easier by giving a code file rather than a DLL. 

When to use a ChannelFactory i.e. a shared DLL?

A DLL is helpful if the client code is under you control and you'd like to: share more than just the service contract with the client -- such as some utility methods associated with entities and make the client & the service code more tightly bound. If you know that your entities will not change much and the client code is less, then a DLL would work better than a proxy. Proxies have several restrictions like:

1. Properties need to have gets and sets
2. Contructors can't be exposed
3. Methods other than the service contract cannot be exposed

What all to package in the DLL?

You'll need to package the following:

1. Entities
2. Service contract -- the interface
3. RequestMsg classes (if any)
4. ResponseMsg classes (if any)

So if you are designing a connected system and using WCF for that, then you can use a shared dll instead of a proxy, to avoid code repetition and be more effective in the use of the service entities.