Infosys | Microsoft

Generally WCF has no  restrictions on the maximum size of the message that can be passed across the wire. Technically speaking, the maximum size of a message that can be passed and processed in a typical WCF communication is about 9,223,372,036,854,775,807 bytes  (which is about 8.5 billion GB!). That is, only if you explicity allow the WCF service and client to receive messages of such sizes. However, there are certain caveats to keep in mind.

For most part, it is possible to set maxReceivedMessageSize attribute to a large value (the defualt being 64KB) to get it going. If a plain large object (say of size 22 MB) is serialized while sending across the wire, it would work just as well as it may not have objects nested within one another. But in cases where there are too many nested objects, with many nested Lists containing a large number of items (say 10,000) embedded, then the number of objects going across the wire crosses the default limit of 65,536.

This restriction is placed to prevent Denial of Service attacks. But by configuring dataContractSerializer you can pass such complex objects of large sizes. This attibute is not available through the bindings, but actually as an extension of the service and endpoint behavior. The value needs to be set in both the client and the server.

Client
        <endpointBehaviors>
          <behavior name="ClientBehavior">
            <dataContractSerializer maxItemsInObjectGraph="10000000"/>
          </behavior>
        </endpointBehaviors>

Server
      <serviceBehaviors>
        <behavior name="HostBehavior">
          <dataContractSerializer maxItemsInObjectGraph="10000000"/>
        </behavior>
      <serviceBehaviors>

Once this behavior is set, the WCF service and client can send and receive not only large objects, but also highly complex ones.

Posted by Kishore Gopalan at 02:20 PM | Permalink | Comments (0) | TrackBacks (0)

I recently came across this nice article on how to get the UAC elevation request working for our own applications in Vista. There are however one or two additional observations that I wanted to capture.

First is that the behavior is seen when directly executing the application. If you compile and debug via VS2005,  you won't see the elevation request poping up. Additionally, if you run your VS2005 as Administrator, then the application will also run in that mode and hence the label will display "Yup".

The other observation is that if you disable the UAC via control panel for your login, the elevation request popup won't occur when you run the application (outside of VS also) or for any other application for that matter. This is also indicated by a regular icon for the application and the security shield is no longer visible. 

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

As people start to write code for BizTalk 2006, it is also expected that people will reuse their existing code developed for BizTalk 2004 and use the Visual Studio 2005's upgrade feature to upgrade the code. Here I am not discussing about the upgrade as such, but more from the deployment after the upgrade.

When you build and deploy a BizTalk 2004 code upgraded to BizTalk 2006, you might get an error as - "error DEPLOY: The database or the database version is incompatible with the installed version of this product."

This happens since the deployment database as configured for your BizTalk 2004 isn't going to work for BizTalk 2006 (unless ofcourse you have done an in-place upgrade for your server environment also) since the schema has been changed a bit. The database configuration is part of the .proj.user file for the BizTalk project and though you can modify this property via Project properties wizard, you can as well delete this .proj.user file before you open the solution in VS 2005 for deployment.

The .proj.user file is recreated when you open a project in VS and in case of BizTalk, it will automatically pick up the values for the development and deployment server from BizTalk's registry configuration.

Another error that you might get is - "Deployment could not be started. One or more deployment properties are not configured." and resolution is the same. Delete the .proj.user file.

In general it is a good practice to not to copy .suo and .user files when copying solutions across machines. Even when downloading code, always delete the .suo and .user files before use since these are user specific settings and there is usually no point of using the settings as configured on someone else's machine. The best practice is enfored by configuration control systems and when you check in a VS solution in VSS, it will not check in the .suo and .user files.

The good part is that the new Application property introduced in BizTalk 2006 is actually part of .proj file and hence deleting the .proj.user file won't delete this setting. So you can keep using the same application name, but configure to work with your own databases. 

Posted by Atul Gupta at 09:47 AM | Permalink | Comments (6) | TrackBacks (0)