Infosys | Microsoft

In the  "Roaming Profiles Implementation for SoftGrid-I" we discussed the concept of Softgrid roaming profiles for applications and it's contribution in achieving a true roaming user profile.

I will continue the discussion further and discuss a simple procedure to implement Softgrid Roaming profile in a test lab.

Posted by Vivek Bhatt at 02:16 PM | Permalink | Comments (1) | TrackBacks (0)

Normally in a locked down environemnt in order to enable End Users (EU) to customize application specific settings and other customizations application packagers identify and elevate security permissions to secure NTFS and Registry areas. This is often considered as a security risk and also contributes to effort in troublershooting and identifying such areas on the local system.

SoftGrid eliminates the requirement of elevating security permissions to the restricted area. As Softgrid virtualized applications execute within a virtual environement the user has complete access to the virtual environemnt while executing the application. The advantage is that the users have access to the desired functionality withoutaffecting the state of the host system.

In order to test this feature of Softgrid, I chose Winzip trial version installation.

Posted by Vivek Bhatt at 08:58 AM | Permalink | Comments (0) | TrackBacks (0)

Posted by Vivek Bhatt at 07:04 AM | Permalink | Comments (0) | TrackBacks (0)

Posted by Vivek Bhatt at 06:57 AM | Permalink | Comments (0) | TrackBacks (0)

As the SoftGrid profile is a part of the user profile and is maintained on the shared location hence, when the user logs on and uses and application, the softgrid virtual environment reads all the settings for that application from the UsrVol_sftfs_v1.pkg file. Therefore irrespective of the machine the user logs on from, as opposed to the traditional system, all the applications along with user settings and files are carried to every location, thus implementing a "true Roaming Profile".

Posted by Vivek Bhatt at 03:54 AM | Permalink | Comments (1) | TrackBacks (0)

While sequencing office 2003 I came around an error that says “This action is only valid for products that are currently installed”.The error occurred when I tried running the applications from the shortcuts placed in Start menu of the local machine instead of launching the shortcuts from Softgrid Sequencer.

Further this was not the case with native installation. Later I found out that the application needs to run from the executable where it is installed which is "Q:\...".When I launched the application from it's installation directory it was launched succesfully.

 The reason behind this issue was the virtual environment created by the sequencer that captures all the registry changes made during installation of the application with no changes made to the local machine. The files created at the time of sequencing remain intact whereas the registry changes are captured in the virtual environment and hence not recorded by the local system. That is why local system could not record the installation of the application and it behaves as if no application is installed to the local system.

After this analysis I came to a conclusion that as a standard all applications should either be launched through the softgrid sequencer or directly from the installation directory to avoid any unexpected errors.

Posted by Vivek Bhatt at 03:29 AM | Permalink | Comments (2) | TrackBacks (0)

Recently when working on an application, I was playing around with writing custom http handlers. There is nothing new in that lots has been written about how to build and configure custom http handlers. So when after writing this I decided to configure it in IIS 7 on my Vista machine, I was pleasently surprised to see that I was lost !

IIS 7 UI has changed noticeably from its earlier versions and when I wanted to configure the file extension I wanted my custom handler to work with, I didn't know what to do.

Fortunately, I found that when viewing my particular website in IIS 7, in the two groups that IIS displayed the information (Grouped by Area by default and has ASP.NET and IIS groups), there was an option called Handler Mappings in IIS group. This seemed like the most relevent location where to look further.

Opening the Handler Mappings, the listing for all file extensions registered with various handlers was displayed, so this was the right place. However as I looked for an "Add new file mapping" option, I instead found three options

1. Add Managed Handler...
2. Add Script Map...
3. Add Module Mapping...

Nothing what each of these meant, I clickly opened each and figured out that managed handler had something to do with handlers witten in managed code, script map was to help configuring an executable and module mapping to work with http Modules. For more details do refer to the IIS 7.0 help file installed with IIS or online on technet.

I soon realized that Add Managed Handler is what I need to work with. There is a catch about Application pool setting being Integrated or ISAPI, which again you can get more details about in the IIS 7 help files. I did notice that on my Vista RTM, the two modes were Integrated and Classic. Since I didn't work with pre RTM versions, I can only guess that Classic was earlier called as ISAPI.

OK, so back to adding managed handlers. See the figure below to see how this looks like.

The interesting point is that after adding a custom http handler (you can follow MSDN documentation's How To article for this) and building the site, IIS already seemed to understand that I had a custom Http handler in my application and it displayed it in the Type drop down (HelloWorldHandler in the figure above). I selected it, provided *.sample as the extension I wanted to work with and also gave it a friendly name.
 
Completing the above steps also automatically edited the web.config file to add the necessary information about the custom handler. However unlike earlier where we added <httpHandlers> within <configuration><system.web> node, I got a new entry in the web.config inside of <configuration> node as below

<system.webServer>
    <handlers>
        <add name="Custom Handler" path="*.sample" verb="*" type="HelloWorldHandler"
                     resourceType="Unspecified" />
    </handlers>
</system.webServer>

Finally to test that it all worked, I accessed the handler as http://localhost/MySampleSite/Test.sample and I did see the message displayed on the page as written on the httpHandler code.

Hence when working with IIS 7, one needs to write the implementation class for the http handler and build the project. Configuring in IIS and also making the necessary entries in Web.config is easily taken care via the Add Managed Handler option in IIS 7.

Posted by Atul Gupta at 10:27 AM | Permalink | Comments (4) | TrackBacks (0)

SQL Server 2005 SP2 is now available. Download it from here - http://www.microsoft.com/downloads/details.aspx?FamilyId=d07219b2-1e23-49c8-8f0c-63fa18f26d3a&DisplayLang=en

For other SQL Server 2005 related files, check - http://www.microsoft.com/technet/prodtechnol/sql/2005/downloads/servicepacks/sp2.mspx

Posted by Atul Gupta at 05:16 AM | Permalink | Comments (0) | TrackBacks (0)

Recently a friend was facing issues in sending messages to a private msmq queue on a remote machine. I had worked on this about 4-5 years back and I recalled that I was able to work with remote private queues. So I decided to give it a try again.

Following are things that I found.

1. When working with remote queues, the queue name in the format machinename\private$\queuename doesn't work. This results in an "invalid queue path" error.

2. The queue name has to be mentioned as "FormatName:Direct=OS:machinename\\private$\\queuename". This is necessary since the queue access is internally done using the format name syntax only. The other friendly representation is converted to the FormatName and then used. When working with remote queues, unless there is an AD to resolve the queue name, the friendly name won't work. Check out documentation for details.

For Eg.

    MessageQueue rmQ = new MessageQueue
                                    ("FormatName:Direct=OS:machinename\\private$\\queue");
    rmQ.Send("sent to regular queue - Atul");

3. Further to previous point, note that FormatName is case sensitive. If you mention the earlier string as "FORMATNAME:Direct=OS:machinename\\private$\\queuename", it won't work. Surprisingly, there is no error thrown in this case. "FormatName" part of the string seems to be the only case sensitive part. Others can appear in different case. For eg. You can write "DIRECT". 

4. In case you want to use the machine's IP address the syntax will be "FormatName:Direct=TCP:ipaddress\\private$\\queuename".

For Eg.

    MessageQueue rmQ = new MessageQueue
                                     ("FormatName:Direct=TCP:121.0.0.1\\private$\\queue");
    rmQ.Send("sent to regular queue - Atul");

5. The transactional properties of the queue instance you create in code should match with that of the queue you are trying to send the message to. So in the earlier examples, I was sending message to a non-transactional queue. To send to a transactional queue, the code would be

    MessageQueue rmTxnQ = new MessageQueue
                                            ("FormatName:Direct=OS:machinename\\private$\\queue");
    rmTxnQ.Send("sent to Txn queue - Atul", MessageQueueTransactionType.Single);

If the transactional properties don't match, the message will not be delivered. The surprising part is again, I didn't get any error, and the message just disappeared

6. Finally, when you send messages to remote queue, a temporary outgoing queue is created on your own machine. This is used in case the remote queue is unavailable. If you go to the computer Management console (compmgmt.msc), and expand the Services and Applications / Message Queuing / Outgoing Queues, you would see these queues. The right side of the console should show the details including the state (connected or not) and the IP address(es) for the next hop(s).

Posted by Atul Gupta at 10:06 AM | Permalink | Comments (64) | TrackBacks (1)

.NET framework 2.0 introduced a new feature called Anonymous methods via the delegate keyword. Some more details on this can be found in this MSDN Magazine article.

Working with anonymous methods can be a bit confusing and also make the code a bit difficult to read. Recently a colleague of mine, Vinay, however showed another interesting class and method naming convention.

public class _
{
    public _()
    {
    }

    public void __(string _, string __)
    {
    }
}

The above is perfectly legal C# code and will compile and build successfully. You can call the method in this class as

    _ _ = new _();
    _.__("_", "_");

So much for the class and method naming and cryptic code! Do note however that this code snippet will be a bit more readable with the VS2005 editor and its color coding.

Posted by Atul Gupta at 06:19 AM | Permalink | Comments (0) | TrackBacks (0)

I was trying to build a sample that had a WCF service consuming an input message from MSMQ. Post writing the necessary code when I ran the service and waited for it to pick up the message from MSMQ, nothing happened.

The message was not getting picked up and I wasn't get any exception or an error logged in event log. I didn't know what to do. Since I had used a transactional queue, and the message continued to sit there, I knew this meant that something went wrong while reading the message, but what?

It turns out that there is a way we can get some insight into what went wrong. If there is any other way than what I descibe below, I would love to hear about it.

If one is working with inline with the samples, the typical code for console based service host will look as below

using (ServiceHost serviceHost = new ServiceHost(typeof(MyMSMQService)))
{
    serviceHost.Open();

    // The service can now be accessed.
    Console.WriteLine("The service is ready.");
    Console.WriteLine("Press <ENTER> to terminate service.");
    Console.ReadLine();
}

A little change to this code is what is required to get insight into what's going wrong. The modified code will look like below

using (ServiceHost serviceHost = new ServiceHost(typeof(MyMSMQService)))
{
    serviceHost.Faulted += new EventHandler(serviceHost_Faulted);

    serviceHost.Open();

    // The service can now be accessed.
    Console.WriteLine("The service is ready.");
    Console.WriteLine("Press <ENTER> to terminate service.");
    Console.ReadLine()
}

static void serviceHost_Faulted(object sender, EventArgs e)
{
    Console.WriteLine("Service has faulted");
}

Essentially I have added an event handler to handle the Service Faulted event. This by itself however doesn't give any additional information. However you can put a break point in the event handler and when a fault occurs, the Locals debug window in Visual Studio shows an additional local variable - $exception, and this shows the required details of what went wrong.

In my case, this clearly showed that the problem had happened while trying the deserialize the message from MSMQ. It couldn't be deserialied since the type wasn't known. This meant that the type I had declared didn't match with what was there in the input message and I was then able to resolve the problem.

A few tips when working with msmqIntegrationBinding and WCF

1. Ensure the type you have defined as the input parameter is marked Serializable
2. Decorate the Service as - [ServiceKnownType(typeof(<yourType>))]
3. Good practice to decorate the Interface method as - [OperationContract(IsOneWay = true, Action = "*")]
4. Tab the service method implementation as - [OperationBehavior(TransactionScopeRequired = true, TransactionAutoComplete = true)]
5. Set receiveErrorHandling ="Fault" in the binding details for msmqIntegrationBinding if you want to get fault information. Setting this to "Drop" will just drop the message and you won't know what really happened. Refer to msmqIntegrationBinding documentation for more details

Transaction requirements will ofcourse depend on your application needs, but note that if the queue isn't set as transactional, in case of errors, there will be no way to recover the message since it will be deleted from the queue while reading.

Posted by Atul Gupta at 01:26 PM | Permalink | Comments (2) | TrackBacks (0)

The other day a friend, having read my earlier blog on Settings in .net fwk 2.0 asked me a question about user settings. He had built an application where he was dealing with user settings and though he was getting the required behavior of user settings getting updated everytime he changed some value and using the new value on next load of the application also, but the mystery was he wasn't able to locate where the values were being saved?

I decided to look into this and created a small windows application which had a text box to input new values, a button to assign them and another button whose text would get updated based on the value in the text box. This value, I also storted as user settings by calling Setting.Default.Save(). I ran the application, set a new text and hit the update button and closed the application. When I ran the application again, I did see the button displaying the new value i had assigned in my previous run.

So far so good. I then opened the application configuration file and to my surprise found the initial default entry in the config file for the user setting. However little thought and this made perfect sense. If the user settings were to be stored in the application configuration file, it would require
1. Updating the configuration file to introduce user specific information like use ID to identify different  user sections
2. The previous point would then also require different reading logic for user settings, since then it would have to account for the user ID
3. With multiple users accessing the application and each saving their personalized values in the file, its size would grow and would then cause performance issues due to a larger file to load and parse.

On a side note, when working with VS, you will also notice a few additional files with .vshost extension. These file aren't necessary for actual execution of the application and more for VS's own use. Check out detailed information here.

So if it wasn't application configuration file, where would the values would. The logical explanation was the Documents and Settings directory that is usually used for storing user specific information. But where in this? I know Visual Studio (VS) itself uses directories like C:\Documents and Settings\atulg\Local Settings\Application Data\Microsoft\VisualStudio\8.0 and C:\Documents and Settings\atulg\Application Data\Microsoft\VisualStudio\8.0 to store information, so this is place I looked initially.

However this didn't show up anything convincing. I did get some pointers to isolated storage, but when I searched that directory, I didn't find anything remotely related to the application I was working with. As I continued to search, I decided to search using the application name in the Documents and Settings directory.

Sometimes these simpler methods return results much faster. I immediately found a directory with the name of my application (MyApp) at - C:\Documents and Settings\atulg\Local Settings\Application Data\MyApp. Note that Local Settings and Application Data are usually hidden directories and trying to browse for them in explorer will not show anything unless these are unhidden. For those of you, who are working with Vista, the directory would be C:\Users\atulg\AppData\Local\MyApp.

Opening the above directory, I found additional sub-directory within it and its name was a bit wierd. It was named as <application exe name>_Url_<some crazy combination of alphabets and numbers>. Maybe the crazy combination is base 64 encoding of some information, but that topic is for another day. This directory itself contained another sub directory as the version number of the application. In my case, it was 1.0.0.0. So the entire structure (inside of C:\Documents and Settings\atulg\Local Settings\Application Data\) looked like

MyApp
    MyApp.exe_Url_obmvyvpuihsr0asonav0kebmr40ckxfe
        1.0.0.0

The final directory with version number seemed interesting and this meant that information stored within would be version safe. The surprising part is when I tried by updating the version number and re-running the application, it created another directory below MyApp itself. So the directory now looked like

MyApp
    MyApp.exe_Url_obmvyvpuihsr0asonav0kebmr40ckxfe
        1.0.0.0
    MyApp.exe_Url_tl0clumf2wjtcgmdusso0mmd1cijtrkr
        2.0.0.0

If the newer version was housed within a different subdirectory alltogether, then what purpose the version numbered sub-directory served? I don't have an answer to this right now. However another point I noticed is that when you debug the application via VS, it creates a different directory structure as

MyApp
    MyApp.vshost.exe_Url_obmvyvpuihsr0asonav0kebmr40ckxfe
        1.0.0.0
        2.0.0.0

In this case, the version numbered directories made sense since they are both within the same parent directory.

Getting back to our earlier quest, there exists a file within the version numbered directory called as user.config and needless to say, it is in this file that the information i was seeking existed.

The mystery over the location of persistence of user settings is hence solved. I checked that when modifying the version number of the application, and making a copy of my executable of earlier version, I could see the different values getting stored in appropriate directories. Running a particular version would load the values saved only for that version.

To wrap up, in case you don't want to use the latest stored values and want to revert to the default values, you can call Settings.Default.Reset(). This clears the user setting values from the user.config file also and hence the default values are loaded the next time the application starts up (unless ofcourse you saved a new set of values).

Posted by Atul Gupta at 11:41 AM | Permalink | Comments (11) | TrackBacks (0)

Earlier today I decided to try my hands at building a Windows Communication Foundation (WCF) service on my Vista machine. Since Vista (RTM) comes pre-installed with .net framework 3.0, the necessary components for WCF are already on the machine.

However to work with VS2005 and be able to create WCF based projects, you still need to install the WCF extensions. You can get the necessary files from here - http://www.netfx3.com/blogs/technology_news_and_announcements/archive/2006/12/06/net-framework-3-0-has-been-released.aspx

I started VS 2005 and selected option for creating a new Website (since I wanted to work with WCF hosted on IIS). In the new Website wizard, I selected the option for WCF Service, named it appropriately and selected OK. The wizard created the base boiler plate code which had the service contract, the service implementation and also a DataContract to handle custom types.

With this done, it looked that i was ready to go. I built the project and it built successfully. I then went to my browser and tried to access the .Svc file via the url - http://localhost/TestService/Service.svc. To my surprise I ended up getting a Http 404.3 error stating that .svc MIME map wasn't enabled.

Since .net framework 3.0 comes by default on Vista, this was surprising that WCF service wasn't working already. However I realized that IIS 7.0 doesn't comes installed by default Vista and hence it meant that the necessary settings were not configured properly post my installation of IIS 7.0. Check my earlier blog on installing IIS.

I expected something similar on lines of aspnet_regiis.exe -i to work in this case and inspecting the Windows directory reveled that a similar EXE does exsist for WCF configuration. It is ServiceModelReg.exe and can be found in "C:\Windows\Microsoft.NET\Framework\v3.0\Windows Communication Foundation" directory. I then ran this from command prompt as ServiceModelReg.exe -i and it installed the necessary scriptmaps at the IIS metabase root and folders within.

I than accessed the service URL again, but still didn't succeed. The error this time read "Metadata publishing for this service is currently disabled." and it provided detailed steps on how to solve it. It required me to specific service behavior and I did this by editing the default created Web.config file and modifying the default <behaviors>/<serviceBehaviors> section. The changes done to this section is as highlighted in bold face below

    <behaviors>
      <serviceBehaviors>
        <behavior name="returnFaults" >
          <serviceDebug includeExceptionDetailInFaults="true" />
          <serviceMetadata httpGetEnabled="true" />
        </behavior>
      </serviceBehaviors>
    </behaviors>

With this when I accessed the service URL again, I got the expected page displayed in IIS as shown below.

So far, so good. It was then time to test the working of the service. So I created a new Windows Application and then added a service reference to it. While doing this I again had an error while generating proxy code and it complained about proxy authentication. Making changes to my IE Connection settings, I got past this error.

Finally after adding a button to the form and writing the necessary code behind which looked something like below, I could get the service executing the returning the results.

        private void button1_Click(object sender, EventArgs e)
        {
            localhost.MyServiceClient p = new ServiceClient.localhost.MyServiceClient();
            string result = p.MyOperation1("Atul Gupta");
            MessageBox.Show(result);
        }

Note that the names of service contract, its methods, service class etc are all left as default and hence you would see things like MyServiceClient and MyOperation1. Needless to say that when you build your WCF services, you should change these appropriately.

In general it will also help to follow the instructions for running the WCF samples from SDK. Check the details at - http://msdn2.microsoft.com/en-us/library/ms751527.aspx.

There is one last point about intellisense in the web.config file. It wasn't working for me and I found that it was due to the xml namespace in the Web.config - xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0". The problem is described here - http://weblogs.asp.net/scottgu/archive/2005/12/02/432077.aspx

Posted by Atul Gupta at 12:12 PM | Permalink | Comments (3) | TrackBacks (0)

In one of my previous blogs -  http://infosysblogs.com/microsoft/2006/10/aspnet_20_ajax_extensions_atla.html, I had provided details about invoking web services, without worrying about the hassles of creating proxy and all, from the client side of the ASP.NET applications, using ASP.NET 2.0 AJAX extensions. And I had also mentioned that client-side invocation of the remote (cross-domain) web services is forbidden because of security implications surrounding that. In order to invoke a remote web service, we have to use a local web service, that acts as a bridge service, which in turn invokes the remote web service. I had used such a bridge web service to invoke a remote web service http://www.xmlme.com/WSShakespeare.asmx  – Shakespeare quotes web service – that provides us back with the timeless quotes from not so forgettable protagonists of Shakespeare’s works.

And it has been long time since I blogged on that topic any further and when I get sufficient enthusiasm and time to come back to that, lot of changes have already happened – the major one is the version 1.0 release of ASP.NET AJAX extensions (and in fact ASP.NET AJAX  Feature Set  January CTP is also available in addition to that), apart from plethora of technology previews, evaluation versions of longhorn server, Orcas development tools, Expression Suite products, WPF/E, etc. Immediately after installing the relevant pieces (Well. To be honest, not so before fully overcoming the mental numbness that happens mainly due to the presence of sheer number of upcoming technologies at such a rapid pace  ) I wanted to port the sample piece of code that I wrote based on previous CTP of ASP.NET 2.0 AJAX Extension, to this new version. Not to anybody’s surprise (if anybody gets surprised, he/she might be visiting our planet from far away galaxy  ), it invariably breaks.

In the process of fixing up the code, I have picked up certain new exciting features. The previous sample code worked fine after a bit of tinkering, as exactly as it was, but I felt that the approach to invoke the web service got to be simpler and elegant in this new version. But that sample that worked as exactly as it had been, was still a matter of concern , because the UI of the sample is nothing but a set of text boxes and a button and so the sample is as dull as that application was trivial. To jazz the UI up with less effort and without dealing with javascript and DHTML object model, I have pulled in the pieces of WPF/E CTP. Basic exposure to XAML and ever-expanding intellisense of VS 2005 really makes the wonders to let the developer to add the gizmos to the UI, though he is not professionally trained for that. But I really don’t know whether the designers who don’t deal with products such Expression suite, will feel the same way if they need to deal with XAML . 

The installation of ASP.NET AJAX Extensions 1.0 is simple and straight forward but  the installation of WPF/E CTP SDK would require you to install something more like Visual Studio 2005 Updates to support Web Application projects. See the links http://www.microsoft.com/downloads/details.aspx?FamilyID=ca9d90fa-e8c9-42e3-aa19-08e2c027f5d6&displaylang=en. And http://msdn2.microsoft.com/en-us/asp.net/bb187452.aspx  and release notes for WPF/E for details.

Once all of them got installed, it is time to plunge into some action. As there are a lot of breaking changes between previous versions and the current version, it is better to keep this link http://ajax.asp.net/files/AspNet_AJAX_CTP_to_RC_Whitepaper.aspx handy. Though going through such documents at least cursorily, is a good time-saving process, before we plunge into new version of any technology, unfortunately I  am not the one who normally takes that approach, but I wish I had done that.

The first striking change is that even local web services can not be invoked in the client-side just like that and the web services need to specifically be attributed with “ScriptService” in order to be invoked from the client side scripts. It is a security measure to prevent accessing and exploiting  all web services through not-so-robust (or vulnerable, depends on what side you are) client technologies. Web methods would also require an extra attribute “ScriptMethod” for specific needs, though it is not mandatory one like “ScriptService” attribute. Secondly, there are attribute level changes with respect to the usage of  “ServiceReference” and to invoke web services. But overall, invocation of web services has become simpler and flexible. For example, now, generic client-side error handlers can be connected to more than one web services. But the real killer feature is the introduction of page level methods that can be exposed as web methods in this version of ASP.NET AJAX. It means that there is no need for a separate web service file such as an asmx file. If you wonder, what is the need indeed to embed the web service methods at page level as it would be contrary to the convention that they (Web Services) should be exposed from a centralized place to multiple clients, remember the fact that cross-domain invocation is still not allowable from the client-side technologies and we need to build our own bridge web service for such cross domain access. In such cases, in stead of building the wrapper local web services (.asmx files) unnecessarily, we can use the page level methods that would act as bridge methods to access remote web methods.

So, I took my old sample code and ported into new version of ASP.NET AJAX. I did a few changes in the code (highlighted below) when I took the customary approach of creating a local bridge web service to invoke the remote web service. In this approach, the solution will have a web reference to the remote web service (in this case, it is http://www.xmlme.com/WSShakespeare.asmx  and my local web service will invoke the remote web service by utilizing the proxy created by the VS 2005. The proxy for the local web service would be generated behind the screens, when the web service file is referenced through “asp:ServiceReference” at the server side. This technology would generate all relevant script code that enables the invocation seamlessly from the client side. The generated proxy would be used to invoke web methods. As these web methods are always invoked asynchronously, it is our responsibility to provide callback methods for eventual situations where the operation may succeed or fail.

Before we proceed further, let us take a look at the snapshot of the solution explorer. Ignore the folder “js” that appears in the solution explorer for a moment as we require this only when we integrate WPF/E pieces herewith.

You can see some folder inside App_WebReferences. These folders were created by VS 2005, as I used the Web Reference property of the solution in order to let the VS create a proxy for the remote web service. See the following snapshot of adding a web reference.

Now we have to create a local web service that would consume the remote web service.

The web service code (MyWebService.cs file) is given below. The point to be noted here is, there are additional attributes “ScriptService”  and “ScriptMethod” (of System.Web.Script.Services namespace) that are applied to the web service and its method. This attribute ensures that this web service can be accessed from the client side scripts. This web service in turn consumes the remote web service through the proxy, generated by the VS 2005.

Posted by Ganesan Krishnamurthy at 12:57 AM | Permalink | Comments (0) | TrackBacks (0)

Windows Vista, the successor to Windows XP, has been official released to customers. From Times Square in New York City, Microsoft Chairman Bill Gates hosted the worldwide launch of Windows Vista and the Microsoft Office System 2007. After years of delay, and tons of speculation on which features will make it to the final release and which ones won't, the next generation operating system is finally out into your hands.

Well, but does a launch of this magnitude create any excitement anymore? Ten years ago, Windows 95 was the biggest launch in the history of an operating system. Shops were open at midnight for consumers to buy their first copy of the new revolutionary operating system that would forever change the face of personal computing. And those were the days when the Internet was just beginning to be a phenomenon, with hardly a high speed connection to be found.

Today, although Vista is great for many reasons, I would be surprised if it generated half the excitement as Windows 95. Simply because the world is a much different place today. It's better connected. "Windows" is a daily routine. Start, Programs, Accessories, Lock, Login, Shutdown are all household terms. You check your mails every morning as regularly as you brush your teeth. This is the days of Mobiles, PDAs, Tablets, Blackberries and iPods. And a brand new Operating System is just another new box nicely piled on the Computer aisle.

Vista was plagued with difficulties right from the moment Microsoft came up with an initial list of planned features, way back in 2001. After a two year delay (it was originally planned for 2005), only half of those features found their way into the final product. And many of those make sense only to the technically inclined people, while for the layman it's all about the fancy graphics and the many interesting goodies.

Some features were dropped because of the technical complexities involved wth certain technologies, and others because of the various lawsuits which forced Microsoft to release a version called Vista N for the European Union, otherwise, and more popularly, known as "the version for EU that nobody will use, pay the same price and get less. And no Media Player!"

Windows File System (WinFS or Avalon), supposedly the new way of organizing files on your computer and expected with Vista, was dropped a year before, because it was "technically difficult". The existing Task based desktop of Vista is far from the initial model, which had a sliding Start menu-like vertical tab helping you with all your frequent tasks. And a countless number of small features, which would have made a huge difference to the otherwise docile operating system, went missing half way during the course of its development.

The conventional pixel graphics is now replaced by Vector graphics, the good old IIS is now called Windows Activation Service and runs close to the OS kernel, .NET Framework 3.0 containing the three new technologies driving the next generation Service Oriented development - WPF, WCF and WF is an inherent part of the Operating System, security is highly enhanced.

But despite its delays and shortcomings, Vista is certainly worth paying attention to. You may not be able to enjoy it with your existing laptop or desktop - because Vista's advanced technology requires advanced hardware - but desktop and laptop manufacturers have already started selling Vista-capable machines and will soon have Vista pre-loaded.

If you are planning to switch to Vista, you would have to upgrade your hardware and memory as well. Or stick to our old pal, Windows XP. If you are planning to buy a new computer, make sure you get hold of a Vista loaded one.

Posted by Kishore Gopalan at 11:40 PM | Permalink | Comments (0) | TrackBacks (0)