ATL Server as shared source project
Great news - ATL Server is moving to a shared source project. If you have not already noticed, it was announced on VCBLog. This release enables developers to fix bugs and add new features to ATL Server. Same time they can release new drops more often than Visual C++ releases. As it was pointed out on VCBlog, one of main reasons for the release is that many ATL Server users would like to see the functionality and services provided by ATL Server expanded. Unfortunately because the Visual C++ libraries team has to work on supporting all other VC++ libraries, often feature requests in ATL Server are dropped out of list of new features for a release. We have decided to not constrain the functionality of ATL Server with the VC product cycle and let the ATL Server community move it forward at a greater pace.
You may expect to ATL Server published on CodePlex site around time when February CTP of Visual Studio Orcas is published online. Headers for ATL Server may show up earlier because we are not expecting that ATL changes in February CTP may have impact on them. As for tools and related tests, we have to do some initial testing on the February CTP to ensure they build and run before we publish them. I will keep updating readers of my blog with status of the project during upcoming weeks.
There are several comments on the original post on VC Blog which I would like to address in my reply.
1) We have been discussing which license to use Permissive or Limited Permissive. We had to consider several technical details. First, ATL Server code has dependency on ATL code. Second, source code of tools was only built with VC++ compiler so far and it is not written in platform independent way. With this said, ATL Server can only be used with VC++ compiler and ATL, which pretty much restricts it to the Windows Platform. Also all existing applications that use ATL Server have to target Windows because of restrictions in Visual Studio EULA. Putting this together, ATL Server is already restricted to the Windows Platform and this is why Limited Permissive license have been chosen.
2) Wizards that are part of Visual C++ IDE are tightly integrated with VC++ IDE. I have been looking with IDE team into taking wizards out of IDE such that they can be integrated back into IDE from the shared source project. Unfortunately VC++ IDE does not have the right support for this functionality and there is not a simple way of getting this done. Also in Orcas IDE cannot keep wizards because they are going to crash for end user because ATL Server is not in VC++ install. Unfortunately, right now ATL Server wizards are just gone from IDE. However I am not losing hope that we may find a way of integrating wizards back into IDE sometime in future of the project.
3) Topic of support ATL and ATL Server attributes has been discussed number of times in past years. It is one of those cases when as idea it seems to be good, but in reality it is just a never-ending source of bugs and complains. Overall opinion among internal and external devs is that attributes are not reliable and devs should stay away from using attributes in sources. For example, this is why why all projects in VS2005 default to generating non-attributed ATL and ATL Server code. When we started discussing ATL Server attributes, not surprisingly most folks felt like support for attributes should be just cut from compiler. We have discussed alternatives, but we have not figured out any other simple solution. So going forward VC++ compiler is not going to recognize ATL Server attributes. Before moving to shared source version of ATL Server, developers will have to replace attributed version of the source with non-attributed version. This is possible to achieve by compiling code with /FX switch, which generates code that is injected by the compiler instead of attributes. I think this is good change. There is going to be less code issues in source when attributes are removed. And ATL Server project is going to have less dependency on future changes to VC++ compiler. Also every functionality exposed by the library can be accessed from non-attributed code and removing support for ATL Server attributes is not a showstopper for the project.
I will keep readers of my blog up to date with progress of the project. Once project is published on CodePlex, the site is going to have a forum and blog dedicated to the project. I will post a link to it as soon as it is online. If you have any comments or suggestions, please email them or leave comments on the post.
Comments
Anonymous
January 24, 2007
ATL Server がシェアードソース化！ - ATL ServerAnonymous
June 29, 2007
In retrospect, if you spent 1% of the time wasted on C++/CLI support, attributes would have been the best feature VC team ever did. There is simply nothing that cannot be fixed or enhanced. I frankly lost faith in repeating myself and cannot believe this decision. 'Front-end, front-end, front-end is where its all at'Anonymous
July 04, 2007
I have to disagree on prioritization of ATL attributes over C++/CLI when it comes to where compiler team had to spend their time during VS2005. I believe C++/CLI is very important for C++ developers on Microsoft platform. Programming model of managed languages is a lot simpler than in C++. And when it comes to new framework, any team is going to start thinking about whether they should expose framework in native C or C++ API or in managed .Net API. And it would not surprise me if predominantly the first language of choice is going to be C#. Because it is simpler and yet very powerful programming language. Some teams may decide to specifically target C++ developers and native code with the framework. But most likely they will make such a decision because of business reasons, not because of how simple it is to build a framework in C++ vs. C# and. However for C++ developers to successfully evolve existing applications and to build exciting new applications, they have to have easy way for accessing functionality in any framework no matter it is built in managed or native code. This is the primary goal for C++/CLI – enable C++ developers to have an easy access to any .Net API and any framework that exposes .Net API. For example, let's take a look on WCF. How can a C++ developer build a service oriented application now? Well one may use ATL Server and/or gSoap, or Soap Toolkit, or other tools to create Web Service client or server side service and rely on support for SOAP based exchange. However to access WCF, which is the whole new framework whole purpose of which is to facilitate creation of service oriented applications, C++ developer would have to build an heavy interop layer between managed code and native code using P/Invoke and callable wrappers. Both P/Invoke and R/CCW have significant performance issues and non trivial to use. With C++/CLI it is possible to directly talk with C# proxy created as WCF client or C# implementation of server side service and avoid P/Invoke or RCW. One may build a single DLL with both C# and C++ code in it and with native C API exports and use this DLL as a stub in between native C++ code and WCF communication layer. This is just a single example of ways in which C++/CLI opens up completely a new universe to C++ developers. Same applies to tons of other .Net APIs that are part of .Net Framework or WPF or Workflow framework. To enable C++ developers to have access to these new frameworks is one of many reasons why for VC compiler team it is more important to work on C++/CLI, not on improving ATL attributes. BTW, Herb has a summary of reasons behind design of C++/CLI here, http://www.gotw.ca/publications/C++CLIRationale.pdf. It goes in many details of why C++/CLI is required for C++ developers on Microsoft platforms. I believe C++/CLI work was correctly prioritized for VS2005 and still the compiler team has fixed hundreds of code issues related to support of ATL attributes. But bug flow for ATL attributes does not stop. To fix ATL attributes a significant investment of dev/test time is required. And when we talk about a significant investment of resources, we need to consider everything else the compiler team has on its plate. There are more important work items that may benefit all C++ developers. The compiler team has to do a lot of work around productivity of C++ developer, compiler throughput and support of C++0x. I personally think of ATL attributes as of the least important problem that the compiler team has to worry about for the next or two releases.