Download Sample Solution (166.51 kb)

In this post I will provide some quick notes on how to invoke an executable from an ASP.Net web application or web service to perform some job. Some of the example of this type of uses cases could be as follows:

• Launch Fax Service to send fax from web application
• Launch printing of some documents from web application
• Invoke a third party executable to perform some heavy calculations
• Invoke a build process from web application
• ... and more

Microsoft .Net framework provides a wonderful static method System.Diagnostics.Process.Start. This method has few overloaded versions that you can use. Most versatile is the one that takes System.Diagnostics.ProcessStartInfo object as paramter. Through this object you can configure behaviour of how executable will run. Following code snippet shows how I added a method in my web service to launch a test appplication that I created.

string CreateProcess()
{
 System.Diagnostics.ProcessStartInfo processInfo = new System.Diagnostics.ProcessStartInfo();
 processInfo.FileName = @"C:\TestConsole.exe";
 var proc = System.Diagnostics.Process.Start(processInfo);
 proc.WaitForExit();
 string ret = string.Format("{0} - {1}", proc.Id.ToString(), proc.ExitCode);
 return ret;
}

To verify that web service does actually invoke and gets proper exit code from the console application, I returned a non zero value from that console application. And when the web service client calls the web service, it does recieve the correct exit code from console application.

Notice that I have called WaitForExit method on the process. This will ensure that process and thread will not terminate till console application has finished execution. Following code shows how the above method is invoked when a web service client calls WebMethod.

public class ConsoleLauncher : System.Web.Services.WebService
{
  [WebMethod(EnableSession=true)]
  public string DoIt()
  {
    string sessionValue = Session["TestValue"] as string;
    var id = CreateProcess();
    var newValue = sessionValue + "(0)" + 
       Session["TestValue"] as string + "(" + id + ")";
    Session["TestValue"] = newValue;
    return newValue;
  }
}

Recently one of my clients asked me question about affiliate web stores and how they work. I have been involved in creating affiliate mashup webstore creation for quite some time now. I have created mashup web stores based on Amazon, Ebay, Google etc. affiliate programs. And lot of these stores have been very successful in generating decent revenue for clients. Lately I got introduced to Commission Junction affiliate program by a new client. This client was looking into creating a web store based on Commission Junction web services. In this post I will provide some information on how to use Commission Junction web services to create a targetted web store.

Get Started

• As with every affiliate program, first you need to sign up with Commission Junction affiliate program. Click here to get started with sign up.
• Now you need a develop key from Commission Junction to access their API. It is a simple process. Go to CJ Webservices page and register for a developer key. After completing this step, the key will be sent to your mail box as well as displayed on the page. Save it and keep it safe.

Build The Site

Now that you have completed the registration process and everything, you are all set to build the site. As with any application or web site, you will need data to show some content and products on the site. The data is going to come from Commission Junction web services. Commission Junction provides REST services to access following kind of data.

• Products
• Links
• Advertisers
• Categories

These are bread and butter of making the site. There are some other services available as well. But for now you can focus on these only. You will need to build an API or some sort of agent that can consume REST services to access the data from Commission Junction web service. Since I am mostly doing .Net development these days, so I have a built a nice handy library that hides all the implementation details and downloads the data from web service and makes it available to the web site. You can Contact Me if you are looking into using .Net API.

Now that you have the data, you will need to think about what type of products or category you want to target to build your store. You have all the data for all the categories from advertisers that you signed up for. But that does not mean that you want to create some store that is going to market all type of products. Well, I am not saying that you can not do that. But it is always better to concentrate on one or two categories. That makes it easier for you to create some focused marketing and promotion plan for your web site.

I created a mash up store where I am marketting all products from all advertisers. You can see how the landing page shows all the coupons and deals of the day from all the vendors and then you can navigate to each page to see how the product page combines links, coupons and product list data to display information to user. Click below to see the store in action.

Affiliate Webstore Demo

Here is some error that most of Silverlight developers run into at some point.

An error occurred while trying to make a request to URI 
'http://nave-pc/SilverGridWeb/GridDataService.asmx'.
This could be due to attempting to access a service in a cross-domain way 
without a proper cross-domain policy in place, or a policy that is unsuitable 
for SOAP services. You may need to contact the owner of the service to publish 
a cross-domain policy file and to ensure it allows SOAP-related 
HTTP headers to be sent. This error may also be caused by using internal types 
in the web service proxy without using the InternalsVisibleToAttribute attribute. 
Please see the inner exception for more details.

I had developed cross-domain access web services for Silverlight in the past and all work like a charm. This morning I ran into this issue again while developing a new web service for a new Silverlight application. I knew that I needed to add CrossDomain.xml or ClientAccessPolicy.xml at root of my web application. So I copied those files from existing application to this new one. To my surprise it did not resolve the issue. I tried all kind of tricks and options but nothing seemed to help. Finally I decided to look at Silverlight documentation and see if there is anything new that has been done for Silverlight 3. Last time I did this was for a Silverlight 2.0 application. I could not find anything different in the description of what needed to be done. But then there was something in the sample XML file content for these files that caught my eye and looked different that what I had.

<allow-from http-request-headers="SOAPAction" >

Notice the underlined section. Previously the value in the allowed headers used to be *. Well, that does not seem to work any more. So I replaced it and everything worked fine.

There are some other important points I am going to discuss in this post. A lot of users do not seem to be clear where these cross domain policy files should be placed.

Location of CrossDomain.xml and ClientAccessPolicy.xml

As the documentation states, these should be placed at the root of the application. Although the statement is very clear but it causes lot of confusion about what is root? There are two ways you create a site in IIS, Virtual Directory and Web Application. So if you have a web site foo.com created as a web site in IIS, then the folder containing the content of this site is root of the application. So your policy files go in that folder. If you have created a virtual directory Bar under this web site where your web service is hosted, then the root of the site is still foo.com and not foo.com/bar. To verify it, open IIS log of your application and look for entries for Crossdomain.xml and ClientAccessPolicy.xml. From those entries you can figure out where those files should be located. If the caller is not finding those files, then you should 404 errors in your log file. For example here are entries from my log file.

1.17.30.170 GET /clientaccesspolicy.xml - 80 - 1.17.30.162  404 0 2 1
1.17.30.170 GET /crossdomain.xml - 80 - 1.17.30.162 404 0 2 1

This is very important. If you are hosting your web service in a web application that is created as a virtual directory in Default Web Site then you need to copy these files in wwwroot folder or whatver folder is configured to be default folder for your IIS installation. Copying policy files in your virtual directory is not going to help. You can also verify the location by looking at traffic in fiddler for your web service access.

Content for CrossDomain.xml and ClientAccessPolicy.xml

I have copied the content of these two files below. These files work for me on my my servers for cross domain access from silverlight.

ClientAccessPolicy.xml

<?xml version="1.0" encoding="utf-8"?>
<access-policy>
	<cross-domain-access>
		<policy>
			<allow-from http-request-headers="SOAPAction ">
				<domain uri="*"/>
			</allow-from>
			<grant-to>
				<resource path="/" include-subpaths="true"/>
			</grant-to>
		</policy>
	</cross-domain-access>
</access-policy>

CrossDomain.xml

<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM "http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
	<allow-http-request-headers-from domain="*" headers="SOAPAction,Content-Type"/>
</cross-domain-policy>