Sometimes I'm wondering how CLI would looked like, if there wasn't Reflection. I allow that CLI is designed in a way to be dependant on meta information. In the broad sense it's only meta information that assembly contains. It's required for verification process, late compilation, GC, and for other services. But concern of mine is Reflection as part of managed library, which exposes meta information.

Well written application usually avoids using of Reflection classes. In rare cases System.Type class is used, but not more then as a handler that identifies class. This is because of fact that whatever operation or service Reflection classes provide, it can be achieved more easily and in more verifiable and strict fashion at compile time.

CLI extensively exploits technique of attributed programming in very diverse it's parts: VM, and JIT recognize special attributres, managed (and not only) languages often support their attributes, and finally managed libraries define immense number of custom attributes. Attributed programming brings power technique of the "meta programming" into the CLI. In order to expose attributes to managed libraries Reflection is used. Architects of CLI implicitly say that in order to use attributed programming you need to inspect types at runtime, extract all required attributes, and you can do whatever you want with these data. This idea, as if proves that Reflection is just required. The disgraceful climax of this technology in my opinion is achieved in xml serialization library (fx), where a C# code is generated from attributes that describe xml serialization of type, and then this code is compiled and loaded, and all of these occur at runtime! This is in the worst traditions of script languages, indeed.

Well, then how to benefit from attributed programming, but without using Reflection at runtime? Let's inspect how attributes are used either by VM, JIT, or managed library. Usually some data is collected, or some verifications are run, or some code is injected or generated. I'd try to move as most of processing as possible out of scope of runtime. And what is the better place then compilation to do such a work; either early compilation when sources are compiled or late compilation (JIT, which in my opinion works to late now anyway ) when IL instructions are converted in to machine code. What I would add to compilation is ability to generate additional data as a post compilation process. In this way when you would declare new attribute type, you may specify that post compilation operation is to be performed (naturally this means that some method is invoked by the post compilation process for each application of the attribute). This would allow to prepare data, generate or inject code inplace or in satellite assembly. This effectively moves using of meta information out of runtime.

Some time ago I've downloaded the add-in for VSIP 2003 SDK and was surprised. Microsoft eventually has published its MSSCCI interface. Here is a quotation from documentation that I had installed:

The Source Code Control (SCC) SDK provides resources that enable you to add source code version control capability to the Visual Studio .NET 2003 Integrated Development Environment (IDE). It allows you to plug in any SCC DLL that complies with the SCC API outlined in this documentation. The IDE handles the UI for common SCC operations and defers to the SCC plug-in for some advanced source code control features. An SCC plug-in implements functions to perform SCC operations. The SCC SDK documentation includes installation guidelines, a detailed specification of the SCC API, a skeleton sample of an SCC plug-in, and a test guide to verify integration and operation of the SCC DLL.

So, from now, everyone can download VSIP 2003 SDK Extras, read “Source Code Control SDK” topic and then implement this interface (I mean MSSCCI). Hope this will simplify lives a lot of developers.

I've released eventually the next version of SCCBridge project. I've fixed there several bugs and improved a bit the integration module to Visual Studio .NET 2003.

The latest changes are:

• Fix the bug with adding to repository bunch of projects (reported by Tim at 4/12/2004 7:04:41 PM).
• The client-side cache for integration module to VS.NET is implemented. This allows to improve a bit productivity of this module (reported by Mark Rose at 3/26/2004 3:29:10 AM).
• The “Select Project Dialog“ in integration module was fixed.
• From now the integration module supports MSSCCPRJ.SCC files.
• I've implemented some functionality of MSSCCI ver1.2 that also quicken up integration module. 
• I've changed a bit Test() method of web service. From now it requires user name and password and tries to connect using of them. In case of error it shows stack trace that simplifies configuration of the service.
• From now there is an ability to turn off support of RSA encrypting during login.
• There are also some minor changes in web service (e.g. I've implemented IsControlled() web method that allows to quicken up the integration module to VS.NET).

I've investigated also how to access from web service to SourceSafe database placed on LAN. Take a look at my recommendation in “read me.txt“ file in /BridgeServer web folder. I've included also these recommendations to my documentation.

I've separated binary files from sources. You can download the SCCBridge server, SCCBridge client separately. The sources as solution for Visual Studio .NET 2003 are available by e-mail request. From now, three additional sub projects (SCCDiff, SCCGUI and SCCPSwitcher) are including to sources. Also I've included sources of SharpZipLib for consistency.

I'm keep working on improvement of SCCBridge project and will be thankful for any feedback.

Some time ago we have started to study BizTalk Server 2004. It's rather amazing and useful thing for join of business processes especially when rules by which they are joined are changed sometime. But the feature that do the BizTalk Server something peculiar is supporting of long running processes.

We have studied documentation and examples from SDK, have investigated several problems that were discussed in newsgroups,  and visited a conference concerning use of BizTalk Server 2004 sponsored by Microsoft. But we miss a real-life BizTalk project. This situation eventually can be changed.

Today we have found official announce of BizTalk Server 2004 Developer Competition. The rules of this competition you can find here. The cash prizes for winners are worthy tribute.

So, good luck for all pretendents!

From time to time I like to tell, to express (or even to brag about) what keeps our minds busy. Sometimes it's even useful, and you unexpectedly discover, you are on the edge of community interests, other time you are outsider.

So, what are we doing now? Well, already several years we are working in Multiconn. One of goals of our company is to help to expose mainframe functionality. Many different solutions of this task are available, and even Multiconn provides several different approaches. Now go right to our business - web service as delegate of mainframe.

To be honest, I think mainframes are legacy monsters, dinosaurs. I realize, it's only a bad perspective, but the first experience is often very strong. For us as developers mainframe is a source of data in different formats (sure formats are legacy also): COBOL records, terminal messages, and so on. Our idea is to allow to mainframe to rest in peace and to gracefully consume its data. Combining consumed data in xml form and operation bindings that describe mainframe's application flow, we arrive to a view of mainframe application as a web service.

To achieve this goal we have worked up extension to xml schema that allows mapping schema elements to a data. It should be pointed, it's perfectly legal to extend xml schema. One way to extend it, is to use elements in custom namespace in appInfo element.

The following was to create importer of schema with our extensions. It's somehow similar to xsd.exe tool. Our tool generates classes with annotations XmlXxxAttribute for xml serialization and LayoutXxxAttribute (this is our custom attributes) for instance serializing and deserializing to and from a mainframe data.

The next stage was to create data serializer. This is a counterpart to XmlSerializer. It inspects class meta-data and creates plan for serialization and deserialization.

On the next stage we have worked up wsdl schema bindings for our technology.

After that we have created tool to import wsdl (similar to wsdl.exe) that generates web service which passes input messages to communication layer that serializes and forwards data to mainframe, accepts and deserializes response and returns it to the web service, which in its turn returns result to a client.

The next was communication layer that interacts with mainframe. This layer consists of abstract (general) sublayer and specializations which support different patterns of communications.

As result we have web service implemented in .NET. This web service represents some mainframe's application.

There are plans to generate similar web services in the Java.

A half year ago I had started a new project that allows accessing to SourceSafe repository remotely. Than I've changed my mind and I've decided to implement more common interface for version control systems (not only for SourceSafe). The main reason for creating of such kind project was that we had need in access to remote version control system, but all ports was closed by our ISP. There were several opened ports (25, 110 and 80). So, we even couldn't use the CVS. At that time an idea about some bridge that allows accessing to version control system (actually at that moment we have need in SourceSafe) as a web service (via HTTP) was born.

Before creating own system I've investigated the market and have found several more or less acceptable solutions:

• SourceOffsite - of course the best existing at that moment solution, but it also used some specified TCP/IP port, so we were not be able to use it due to the same reason as we were not be able to use CVS. More over, their prices were the highest for such kind of products.
• Than I had found VssConnect - also not a worst solution, but lack of documentation and they did not support (at that moment) some useful SourceSafe functionality. And that is more important they also used some TCP/IP port. :-( By the way, their prices are more reasonable.
• After that I had started to look for a product, which is implemented as web service. And I've found one: VSS.Net. But they also do not provide some SourceSafe functionality: sharing and branching files, retrieving of history, pinning/unpinning files and etc.  And they do not implement integration in VS IDE. The price of their product a bit higher then the previous one, but still acceptable.

When I had studied these solutions, I've decided to create my own solution. And, since for me this was not a main job, but just an opportunity to study something new in practice, so, I've decided to create this solution as a freeware .NET product.

At the 24 November 2003 I've published the first fully functional version that can be integrated into Visual Studio .NET 2003 IDE. So, my task was done, but right now I see a lot of places where I can improve performance of my product, but I have a doubt: do somebody need in this project at all?

Eventually the fashion on the web logs has rolled to us. This is an amazing thing that allows expressing thoughts about something. The thoughts that could be interesting for many people, but for any reason yet not enough to take shape of an article. We think that such modern feature will do our site more interesting and more useful for our visitors.

Sincerely,
Arthur & Vladimir Nesterovsky