The third part of my series is about folders, paths and versions.

Older articles in this series are:

Part 1: Overview, domain model and bindings

Part 2: Domain model part 1, Repository, Types, and Properties

Folders are well known concept. They are present even in the simplest form of file systems used all over the place. Access by path is also a well known pattern from the files system or from the World Wide Web. Versions are typically not available in a file system but are available in most document management systems. They are essential for any kind of collaborative editing and they can be used to preserve the history of a document.

Folders

In almost any kind of structuring information you will try to define some kind of hierarchy. Folders are a very simple form for such a hierarchy and because of this they are extremely useful. In CMIS every repository can have a folder hierarchy. Each folder has at least one parent folder. There is one special folder without a parent called the root folder. The navigation service in CMIS is used to navigate along the folder hierarchy. There are methods to get the parent(s) for an object or to enumerate the children. Each folder has a unique id. The id of the root folder is part of the repository info. The details how repository implementations implement folders vary. Therefore the CMIS specification has some optional. One of this options allows a  document being  contained in more than one folder. This feature is called multi-filing and is only available for documents. A document therefore can have multiple parents. Folders however always have exactly one parent (except the root folder).  So each folder appears only once in the hierarchy.

Another option is that a repository supports storing documents outside of the folder hierarchy so that it has no parent folder at all. This is called un-filing. Un-filing is often used for archiving scenarios where the main purpose of the repository is to preserve documents for a long time in a stable way. The repository provides an id and the id is stored in a leading application having control about the document and its context.

Please note that CMIS objects that are neither documents nor folders (like relationships or policies) are never contained a folders. This is part of the specification and independent of the un-filing capability.

The specification makes no assumptions about further constraints. So it is valid for a repository to allow folder having two or more objects with the same name. CMIS clients should be prepared for such a repository behavior.

A repository can support the constraint that a folder may contain only objects of certain types. A special property called AllowedChildObjectTypeIDs is used to control this behavior.

Path Access

In many cases objects are identified by the path. The path points to the location in the folder hierarchy with a special character ‘/’ separating the folders. A path is another mechanism to access a document in addition to the object id. Paths are used  in the World Wide Web (URL) or from file systems. CMIS supports retrieving objects by their path (getObjectByPath in the ObjectService) or by their id (getObject). Be aware that a path to a document does not have to be unique. With multi-filing a document can be in multiple folders and so have more than one  path. For this reason there is also no method like getPath() that returns the path to an object. Instead you have to use the getObjectParents() method that returns relativePathSegment strings. A relative path segment is the part of the path to be used to address the object in this parent folder.

A CMIS client should not assume that the name of an object is part of its path. I f a repository supports multiple objects with the name in a folder this path would not be unique. Therefore use the pathSegment output of the getChildren() method in the Navigations Service instead. This is guaranteed to be unique. Because calculation can be expensive you explicitly have to ask for it (by setting the includePathSegment parameter to true).

Paths are not stable. If an object is moved from one folder to another it’s path will be changed. For this reason it is in general not a good idea to use path access for archiving scenarios. The id is the preferred choice in this case (however the behavior of repositories may vary regarding the stability of ids for example after updating an object).

Versions

A document in CMIS can exist in multiple versions. Only documents can be versioned, other objects like folders, relationships, etc. can’t be versioned. Not every document can be versioned. Whether versioning is supported or not is determined by the Document Type (versionable property). CMIS supports a simple linear versioning model. Versions can be major or minor. A version series indicates all versions that belong to one document. A version series has an id. The VersioningService is used to create and access versions. To create a new version in a version series the document needs to be checked out. After checking out you get a private working copy (PWC). A private working copy also has an id. Only one PWC can exist at any point in time for a version series. A PWC can be updated and edited by the user who owns the PWC. To create a new version the PWC has to be checked-in. The check-in operation indicates whether a major or minor version is created. The cancelCheckIn method discards the private working copy (and any change will get lost). Whether a PWC is visible to others and for example can be returned by a query is repository specific. It is also repository specific if other versions except the PWC can be edited or updated. The RepositoryInfo structure gives you certain information about this. The versionSeriesId is a property of a versioned document. Its presence indicates that multiple versions of this document exist. The CMIS specification makes no assumptions what other operations are allowed with a versionSeriesId as input parameter. This is repository specific. The specification also does not define the behavior of properties for versions. Each version has a set of associated properties; some of them are specific to the version (like the version number).  A client should be prepared that some repositories may internally map certain properties to the version series and not the individual version. So if it is changed for one version it may change for all other versions as well. In a query a client can request if he wants to retrieve all versions of a document. A repository can support (see RepositoryInfo) that versions can be stored in different folders (version specific filing). A relation can be tied to a version or to a version series (repository specifc).


Domain Model I, Repositories, Types and Properties

In the first part of the series we learned about the general structure of the standard, its idea and purpose.  Now it is time to take a closer look at the core of the standard the CMIS Domain Model. The Domain model describes the services, their methods and the fundamental data structures.

Older articles in this series are:

Part 1: Overview, domain model and bindings

The Repository

If you want to use CMIS you always the first object you have to deal with is a repository. A repository is the topmost object in CMIS and can be seen as a data store. One CMIS implementation can maintain multiple repositories. Different repositories can contain different kind of data, or they can contain data stored in different physical locations. Different repositories may also have different capabilities (for example because they are optimized for a specific need). They even can be a  virtual entity unifying different physical repositories under one umbrella. All this is up to the vendor and CMIS implementer, the standard makes no assumption about where one repository differs from another.  But each CMIS implementation must have at least one repository (identified by a repository id). Repositories are accessed in CMIS using the RepositoryService. A client always needs a URL to access a CMIS server. For the WS (web service) binding you need to get a URL for each CMIS (web) service. For Atom you only get one URL identifying the AtomPub service document. For AtomPub you can easily start just using a browser. For example if you setup OpenCMIS from the Apache Chemistry project you get a default repository for testing purposes that you can deploy as a .war application in a servlet container like Tomcat. (Well to be precise there are two different servers: one that acts on a file system and the other is just an in-memory server).  If you build OpenCMIS you will find a file chemistry-opencmis-server-inmemory-0.1-incubating-SNAPSHOT.war. For easier handling we will rename it to opencmis.war and copy this to the webapp application directory of the Tomcat installation.

Now open a browser and type in the address field:

http://localhost:8080/opencmis/atom

If everything is okay the browser will reply with a dialog box what to do with the data of type  application/atomsvc+xml. Just save the response to a file named opencmis.xml and open it in a text editor. You will notice a standard XML document containing entries for each repository (in this case only one). This XML contains a number of links that you can use to access the information in this repository and to make use of the other CMIS calls. If you like to continue along this path there is an excellent tutorial from Jeff Potts: Getting Started with CMIS.

If you want to test the web service try to enter the following URL in your browser:

http://localhost:8080/opencmis/services/RepositoryService?wsdl

You will get the WSDL for the RepositoryService as response. You can use this WSDL to import it in a tool of your choice that typically will generate a client stub for a target platform.

Great, now you have made your first CMIS calls, let’s look a bit deeper what is available!

You also can ask a repository about its capabilities. Not all repositories provide the same functionality, but a CMIS client should be able to discover if it can interact with a given repository. CMIS supports a wide range of potentially very different repositories (even a file system can be mapped to CMIS). But many clients will require a minimum set of functionality to operate. We will explain the supported capabilities when we discuss the corresponding functionality in the next sections.

The Type System

Now we have access to a repository. If we want to be able to store millions of documents there and efficiently retrieve them later we need to define some structure to manage all this information. Most repositories use types as one mechanism to structure this information. If you look at the local hard disk of your computer you see the familiar hierarchical file system consisting of files and folders. A typical ECM system provides more mechanisms to differentiate between various kinds of files and folders. Files and folders (and there are even more objects) have a type. A type indicates what kind of an object contained in a repository is and it has properties that can be filled with values. You already know some properties from the file system like creation date, or the time it was last modified. These system properties are supported by CMIS as well. In addition a user (or in most cases some kind of administrator) can assign user defined properties to an object. Think about an email for example: An email has a subject, a sender and a list of recipients. An invoice in an ERP system might have an invoice number, an associated order number, an amount and a customer number. Because all emails are similar and all invoices have the same structure we can define a type email and a type invoice. Such a type definition can enforce constraints. For example we can define that every email must have a sender and may have a subject. For the invoice we may even be more restrictive and define that it must have an invoice number and that this number must not be shorter than a min and must not exceed a max length. Each property has a type and a set of possible additional constraints. CMIS supports the following property types:

  • Boolean
  • String
  • Decimal
  • Id
  • Integer
  • Html
  • DateTime
  • URI

Each property type has a set of possible constraints. Each type definition contains the actual constraints for its properties. In addition a property can be assigned to be mandatory (must be provided by a client), to be read-only or modifiable. The queryable attribute on a property indicates whether you can use it in a query. CMIS also supports that a property value must be one element of a fixed or an extensible list of predefined  values (like property color must have a value of red, green, yellow, blue or black). These field values can even be hierarchical like in fruits/apples, cherries, strawberries; vegetables/tomatoes, cucumbers, beans. A property can be single-valued or multi valued (for example an author property of a type book may allow multiple authors). Each property and each type has an id, a name and a description. This list is not complete, property and type definitions are more complex than described here, but you should have got an impression what you can do with types and properties in repositories. Types can enforce certain rules on your data in your repository and they also provide means to efficiently find objects in the repository (which we cover later). For further details about types and properties take a look at the CMIS specification.

It is important to note that CMIS in the current version does not allow you to create type definitions from a client. You either have to use the vendor specific API of your repository to create a type definition or you have to use an administrative user interface to create a type definition. CMIS does however expose all the available types that currently exist in a repository. The methods to do this are contained in the RepositoryService (for example getTypeDefinition).  Each type definition has a unique id within the repository and each property definition has a unique id within the type definition.

CMIS also has some predefined types. There is for documents cmis:document and for folders cmis: folder. Those types are generic and do not have any additional properties (except the standard properties that exist on every type). Other predefined (optional) types like cmis:relationship and cmis:policy will be covered in one of the next articles. The cmis: prefix indicates that these type definitions are part of the standard. This namespace is reserved for future extensions of the standard and must not be used for any other purpose.

Type Hierarchy

Imagine you have stored thousands of invoices in your repository and now the government introduces a new law that each invoice must have a tax number included. No problem you just add a new property “TaxNumber”. But on one hand you would like to make the new property mandatory because it is enforced by law, on the other hand you already have thousands of invoices from the past without such a number. You could create a new type definition for the new invoice but this makes things complicated if you search for invoices. You suddenly have to deal with two invoice types instead of one which is confusing for end users. For situations like this (and many others) it is convenient that you can derive a type from an existing type. So you can introduce a type “InvoiceWithTaxNo” that inherits everything from “Invoice” but adds an additional mandatory field for the tax number. Because an object of type InvoiceWithTaxNo behaves exactly like Invoice a query for invoices can include the subclasses. This mechanism is called type inheritance and CMIS allows types to be inherited. The structure describing the type definitions indicates the parent types. The topmost parent is called base type and is always one of the predefined types cmis:document, cmis:folder, cmis:relationship or cmis:policy.

Folders

Folders are a second mechanism to structure information in a repository. Files and folders are a very common structure from file systems. Each folder in a repository has exactly one parent folder with the exception of the root folder. The id of the root folder can be retrieved from getRepositoryInfo(). The navigation service contains methods to browse the folder hierarchy. Compared to a file system folders in CMIS are typed (see above) and so have properties. A folder also can impose additional constraints, for example allow only objects of certain types as children. CMIS does not enforce that all children in a folder have a unique name. This is up to an implementation to enforce this constraint or not.

Documents

Documents are the main entity managed by CMIS. Each document has a type. Whether a document must be contained in a folder or not is implementation specific (unfiling support). In contrast to a folder a document can be contained in more than one folder. Again this is an optional feature (multi filing support) of an implementation. Whether  multi-filing or unfiling is supported can be determined from the capabilities in a getRepositoryInfo() call. A document can have content but this is not a requirement. The document type indicates whether content can be attached or is mandatory (contentStreamAllowed property). The document type also indicates whether a document can exist in multiple versions (versionable property). Repositories behave differently in regards how content of an existing document can be changed. This information can be retrieved from the capabilities returned from  a getRepositoryInfo()  call (capabilityContentStreamUpdatability).

Some repositories also support more than one content stream per document. This can be used for more complex documents (e.g. different chapters), multiple scanned pages or other additional information like signatures, annotations, etc. This is currently not supported by CMIS (there is one exception which we will cover in the rendition chapter).  A content stream has a stream id, a MIME type and a length.

Documents and folders together with other objects are created, accessed, manipulated and deleted with the ObjectService in CMIS.


CMIS Logo

The CMIS standard is now official; many companies have announced supporting this initiative including all leading vendors of ECM systems. There is circulating a lot of information around the standard about who supports it, how it will influence the ECM industry, potential use cases and so on. But there is very few information available about what the standard is, what you can do with it and how it technically works. There is the official specification of course, but this not the right level for getting a first impression and not everyone is willing to read through the 236 pages. So I guess it is time for an article that focuses on the technical aspects without digging too much into details of wire protocols or source code (we might use it here and there for clarification but this is not the focus). This first part is the start of a series of giving an overview about CMIS. Hopefully you get an idea at the end what you can do with CMIS and whether it makes sense for you to buy into it.

Enjoy it and of course I am interested in getting feedback. Here an overview about the parts (subject to change)

Part 1: Overview, domain model and bindings

Part 2: Domain model part 1, Repository, Types, and Properties

Part 3: Domain model part 2, Versions, Relationships, Query

Part 4: Domain model part 3, Renditions, Permissions, ACLs, Policies

Part 5: Extensibility and Protocol differences, Compatibility

Part 6: Summary, Future Enhancements and Outlook

Part 1: Overview, Parts of the standard, model and protocols

CMIS is about interoperability between ECM systems. So let’s first take a step back and have a look what an ECM system is: Wikipedia defines it as “strategies, methods and tools used to capture, manage, store, preserve, and deliver content and documents related to an organization and its processes”. What does this mean? Often we differentiate between structured and unstructured information. Structured information consists of data that repeatedly occurs in very similar or identical forms. If structured data are processed paper-based, often forms are used. They keep their structure over long periods of time. Addresses and postal codes are examples, an inventory management that structures storage locations according to different capabilities and their physical location or a catalog of goods dealing with articles, article numbers, availability, prices and so on. Access to data often is done by queries that occur over and over again in the same form. Structured information can be handled efficiently in relational databases and over decades software has been built around managing all kinds of such structured information.

Many business processes however deal with data that is much more unstructured, contained in documents or images, voice and video. Data in form of natural language, pixels, audio samples or video frames is much harder to process. They need to be stored efficiently and should be findable and retrievable even after years. ECM systems deal with processing and management of such kind of information. A relational database alone is often not sufficient to manage these kinds of data. ECM is about managing your content.  CMIS tries to standardize storing, retrieving and finding content and therefore allows exchanging information between different ECM repositories. The nature of lacking structure implies that ECM repositories follow very different approaches how to achieve this goal. Often they are specialized on only a few aspects, scenarios or data types that they can handle efficiently. Many special features exist that just make sense in a specific area, resulting in a wide heterogeneity of systems. Trying to standardize something in such an environment is a challenge. You need to find the right balance: On one hand it should be possible for a standard to be fulfilled by as many systems as possible. On the other hand you want to cover as much functionality as possible so that the standard is useful in a wide range of business cases and scenarios. CMIS tries to focus on the common parts that exist in most of the available systems today. When in doubt if a feature makes sense or can’t be implemented by most of the systems the TC (OASIS Technical committee) rejected it in favor of keeping the standard simple and easier to implement. So it is likely that you will miss one or the other feature of your favored system.

What all systems have in common is the capability to bring structure in the information with metadata that go along with the content. They assist you in finding the information by various means and they try to control who can see and modify the information. All this is part of the CMIS Domain Model. We will take a closer look at the domain model in the next parts of the series. The domain model is the core of the standard.

The domain model describes the objects, methods and what you can do with them. It does not describe how you technically get access to them and perform actions on them. There are several possible ways to approach this: You could for example describe an API in a programming language, you could describe a file format or you can agree on a network protocol to exchange information. You even can omit this completely and define it as outside of the scope of the standard. Each approach has its strengths and weaknesses and there is no simple answer to what the best approach is. CMIS decided to standardize on protocol level and calls this bindings.

The reasons for this are that the TC has seen interoperability between as many systems as possible as fundamental. In today’s world there is much more agreement on network protocols then on APIs. An API is always tied to a platform and programming language. But ECM systems are available on very different platforms and implemented in a wide range of different programming languages. It was essential that the Java and Microsoft platforms can be covered adequately as they are the most important platforms today. The downside of this approach is that it is much easier to implement an API for a programmer than to deal with all the details of a network protocol. If more than one protocol needs to be supported things get significantly harder.

In the current release CMIS defines two different bindings: The RESTful AtomPub binding and a SOAP binding for web services. To cover a wide range of systems the TC decided to define two different bindings with different characteristics. The SOAP binding supports the widely used web service standard as transport mechanism. Web services are supported by many different platforms, they are available for a long time and good tooling support is available. Web services also offer a wide range of advanced functionalities like encryption, transaction handling and more on top of the basic protocol. But web services are also criticized because the standard is complex, the protocol not very efficient on the wire and it hardly can be used without any tool support. To offer an alternative the CMIS TC decided to standardize in addition a second protocol following a different  (more RESTful) paradigm. This is based on the Atom Publishing Protocol (AtomPub or APP) specification. AtomPub is defined in RFC4287 by the IETF. The AtomPub protocol is XML transferred over http. By using AtomPub simple CMIS requests can even be handled using a web browser.

Fully CMIS compliant repositories have to support both bindings. From what we can see today (which is pretty early of course) it seems that the AtomPub protocol is the more popular one.

Having a library available that offers interfaces, classes and methods can make implementing the standard much easier. It can guarantee the conformance on wire level, provide familiar data types and method conventions and most important: offer support for both bindings transparently to the programmer (if designed in the right way). Over time it is expected to see a number of available libraries for different platforms. Announced or available are for example Android, iPhone, Java, Python and PHP. The most complete functionality today is available in Java in the Apache Chemistry/OpenCMIS project. Chemistry offers support for client and server for SOAP and AtomPub   and covers the full scope of the specification.

CMIS is not the first attempt for a standard in the ECM area. Other initiatives like JSR 283, JSR 170, WebDAV and some older initiatives like DMA and ODMA either are related to CMIS or overlap. Within the remainder of these series we may take a look here and there how they compare, but an in-depth comparison is out-of-scope.

This introduction should give you a first overview about the CMIS standard. Lets’ look forward to the next part introducing the domain model and giving you a handle to more concrete things you can do with CMIS.

References

OASIS CMIS Technical Committee: http://www.oasis-open.org/committees/cmis/

CMIS 1.0 Specification:  http://www.oasis-open.org/committees/download.php/36486/CMIS-cd07.zip

AtomPub Specification: http://www.ietf.org/rfc/rfc4287.txt

Web Services:  http://www.w3.org/standards/webofservices

Apache Chemistry: http://incubator.apache.org/chemistry/




There are a lot of posts around the topic how to compile for Windows 64-Bit with the VC2008 Express editions. The documentation is weak here and you find a lot of posts with questions around this topics. As I could not find any solution around this I started digging a bit deeper into the problem, to see what went wrong and how to fix it. Not sure if Microsoft officially supports this or prevents this intentionally, but there is a way to get a clean configuration with preserving all the nice things Visual Studio offers. Unfortunately it requires modifying the registry and copying some files. Hopefully Microsoft comes up with something better in the next version. While the full version of Visual Studio works flawless and as documented I struggled a couple of evenings to get it running with the Express version. Here are the details (I recommend reading first the full article before you try the modifications):

The Documentation

The basic instructions how to enable 64-Bit targets are here: http://msdn.microsoft.com/en-us/library/ms185328.aspx. You start the configuration manager to create an x64 Target in addition to Win32. For the Express version you first need to install the Windows SDK (former Platform SDK) and configure VC to use the installed SDK instead of its own SDK. There are many instructions around how to do this. Now the documentation says: On the Build menu, click Configuration Manager. 1.In the Active solution platform list, select the 64-bit platform for the solution to target. If the platform does not exist in the list, select New. 2.In the New Solution Platform dialog box, select the 64-bit platform for the solution to target. Note: If you create a new name for your configuration, you may have to modify the settings in the Project Designer to target the correct platform. 3.If you want to copy the settings from a current platform configuration, select the platform configuration to copy settings from, and click OK. But the issue is: if you use the Express edition you don’t see the x64 option in step 2. It simply does not exist. Also if you open Tools/Options and then go to Projects and Solutions / VC++ Directories you will find under platform only Win32 and not x64 (as in the full version). Here ends the documentation and there is no information available where Visual Studio gets this information from and how a platform can be added. The Solution The next step is to find out where VStudio gets the available platforms from. Open the registry editor (regedit.exe) and navigate to [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Visual Studio\9.0\VC\VC_OBJECTS_PLATFORM_INFO\]. Below this key all the available platforms are listed. You should find here two subkeys Win32 and Win64 (AMD64). The SDK installer creates these keys if it detects a Visual Studio. This works fine for the full version. The problem is that the Express version does not get the information from this path, but all its configuration is located in [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VCExpress]. So select VC_OBJECTS_PLATFORM_INFO in the registry editor and export this to a text file (.reg). Open this text file in a text editor (like Notepad) and replace all lines with brackets like this: [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\9.0\VC\VC_OBJECTS_PLATFORM_INFO]to [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VCExpress\9.0\VC\VC_OBJECTS_PLATFORM_INFO] Double click the modified file and confirm to update the registry. However we are not done yet. This information contains only a class id and this information is also in the registry and needs to get moved. Navigate to: [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\9.0\CLSID\ There are 4 class ids meaningful for 64-Bit compilation (I am not 100% sure if you really need them all).

{656d8763-2429-11d7-8bf6-00b0d03daa06}{656d8760-2429-11d7-8bf6-00b0d03daa06}{656d8763-2429-11d7-8bf6-00b0d03daa06}
{656d875f-2429-11d7-8bf6-00b0d03daa06}

Repeat the steps from above for each of these class ids (select the id in the registry editor, export to a .reg file and change there all lines having the […]. Replace the string VisualStudio with VcExpress. Save the modified file, double click and import it to the registry.

For each available platform VStudio needs to get the correct directories where the compilers, headers and libs are. You can see those in Tools/Options and then go to Projects and Solutions / VC++ Directories. So where do they come from? It seems that VStudio scans the directory $(InstallDir)\VC\vcpackages (where install dir is the installation directory, e.g. c:\program files\Microsoft Visual Studio 9.0). It seems that all files containing the extension „.config“ are used to import the directories for the various platforms. These are readable xml files. The name of the file is not meaningful but in the xml part there is a GUID making the back reference which platform it describes. The SDK installer therefore copies the file named AMD64.VCPlatform.config containing the appropriate information to this directory. However there is another subtle difference (for whatever reason…) between Visual Studio and Visual Studio Express. Whereas the full version scans for files named .config the express version scans for files ending with .Express.config. Therefore rename the file from AMD64.VCPlatform.config to AMD64.VCPlatform.Express.config. Now open again Visual Studio (note that each change requires a restart of Visual Studio Express!) and check again the platforms in Tools/Options /Projects and Solutions / VC++ Directories. In the platform box you should now see two options (Win 32 and x64). Select x64 and check that there is a list of suitable directories in place. If x64 does not appear something went wrong in the first step. If x64 is available but the list of directories is empty something is wrong with the renaming of the .config file. If everything is fine you have the platform properly configured now and can proceed with the Configuration Manager to add the new platform to your project (for details see MSDN documentation about 64-Bit programming, link is above).

Note 1: Be aware that there exist two 64 bit compilers. One which is itself a 64 bit program and another one is a cross compiler running at 32-Bit but producing 64-bit object files. Be sure that you don’t take the wrong one (normally always the cross compiler is used).

Note 2: The same procedure should work with other platforms like IA64 for Itanium with of course different file names and GUIDs. The structure is the same, the DLL is named VCProjectIA64Platform.dll and the configuration file is Itanium.VCPlatform.Express.config. However I did not try this.

VC2008 Express installed on a 64-bit operating system

All instructions so far have been valid when Visual C++ is installed on a 32-Bit operating system. If it is installed on a 64-Bit operating system there are some more pitfalls (and presumably bugs in the SDK installer). At first there is a special branch in the registry for 32-Bit applications on 64-Bit operating system. So all paths in the registry mentioned above have to be changed from: [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VCExpress\9.0\ ...] to [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\VCExpress\9.0\…} The second change is an even more subtle bug: The 64-Bit C++ compiler exists in two flavors. One is a cross compiler running on 32-Bit (installed in …\VC\bin\x86_amd64) and the other is 64-Bit application (installed in …\VC\bin\amd64). If SDK installer detects a 64-Bit operating system it copies the 64-Bit version of the VCProjectAMD64Platform.dll to the …\VC\vcpackages directory. However this makes absolutely no sense since the VC200 Express is always (at the time of this writing) a 32-bit application. So you have to manually copy VCProjectAMD64Platform.dll from $($VCDIR)\VC\bin\x86_amd64 to ($VCDIR)\VC\vcpackages. $(VCDIR) means in this case the directory where your VC2008 is installed, e.g. c:\Program Files\Microsoft Visual Studio 9.0. There is no easy way to check whether you have the 32-Bit or the 64-Bit version of the DLL installed. Both have the same name and version. The easiest way to differentiate them is to look at the file size: The 32-Bit has 283KB the 64-Bit version has 370KB. Using VC2008Express on 64-Bit system has the advantage that you can debug your applications in the same environment where you compiled them.

Conclusion

I have no clue if this is a bug in the SDK installer or if this limitation is intended by Microsoft. To me it seems that someone made a decision like „Oh let’s separate Express version from full version completely by just taking a different branch in the registry“ But the impact of such a decision was a subtle change in the interface that no one has considered and/or was not very well communicated between the different teams. …like so often in software development. Yes the fix is nasty and changes in the registry like this are a bit dangerous too but once done it works really nice! Let’s hope that Microsoft fixes this in the next version of the SDK and gives us all the more and more important benefit of 64-Bit in the Express editions.

Addendum

Here is some additional information from reader contributions. Thanks to everyone who provided feedback and helped to improve this.

Missing VCProjectAMD64Platform.dll:

It seems that under some circumstances the 32-Bit version of this  DLL does not get installed if you are on a 64-Bit OS. So you won’t find it in $($VCDIR)\VC\bin\x86_amd64. In this case you either have to copy it from an installation on a 32-Bit OS or extract it from the SDK installer medium. The DLL is located in the ISO distribution’s \Setup dir in the vc_stdx86.cab. It starts with FL_VCProjectAMD64Platform…if you rename it to the proper name it should work. Thanks Dustin for this helpful hint!

Xia Wei provided a helpful script that automates this tweaking. I did not try this myself but after a couple of positive reader comments it’s definitely worth mentioning it here. Download is available here: http://suma.soulogic.com/dl/VCE64BIT.zip

Latest info from Xia:

Win7 SDK introduces 2 new bugs and they may cause this patch not to work, I describled them as well as workarounds here:
http://www.cppblog.com/xcpp/archive/2009/09/09/vc2008express_64bit_win7sdk.html

Updated patch for Win7 SDK:
http://www.cppblog.com/Files/xcpp/VCE64BIT_WIN7SDK.zip




Follow

Get every new post delivered to your Inbox.