Description of problem: There is need to support Microsoft Visual Studio 2010 by qpid winsdk package as Microsoft does not sell icrosoft Visual Studio 2008 anymore.
*** Bug 675833 has been marked as a duplicate of this bug. ***
I tried building qpid/trunk on 11-Feb-2010 with the following issues: 1. Boost We currently ship Boost 1_39. Boost 1_39 does not work under VS 2010. Boost requires an upgrade/rebuild to 1_46 or so. 2. CMake requires help finding later versions of Boost set (Boost_ADDITIONAL_VERSIONS "1.46.0" "1.46") 3. Visual Studio 2010 includes native support for TR1. Disable that to use the Boost version. In CMake Windows add_definitions: /D "_HAS_CPP0x=0" 4. VS2010 introduces an "int8_t" that conflicts with Qpid's definition. In integer_types.h change qpid's definition to: #typedef unsigned char int8_t 5. QPID-2643 Compile fails. In include/qpid/framing/list.h add one line: typedef ValuePtr value_type; 6. Various build scripts have VS2008 hard-coded into them. They need work to do VS2008 and/or VS2010. 7. [Unsolved] Various template function compile failures in the broker. Here current development work stopped. Beyond that we will need: 8. A new VM from MikeB in build engineering that has VS2010 and support for everything listed so far. 9. New packaging to support the MSVC 2010 runtime. 10. Some engineering and QA smoke testing to see if the results hang together. FYI: I had a face to face meeting with Steve Huston, a respected non-Red Hat windows developer. He had problems trying to move to VS2010 and since then he has stuck to VS2008.
See https://issues.apache.org/jira/browse/QPID-2643
VS2010 build progress: The good news is that the process almost builds VS2008 SDK again, dodging all the regressions. Lessons learned along the way so far: 1. CMake generator for VS2010 introduces quirks. Usually simple but some scripts may need an on-the-fly sed to get a 2010 build to work. 2. bld-winsdk script must 'login' to VS2008 or VS2010 to select a 'devenv'. This was not an issue when there was no choice of Visual Studio version. Getting this right is tedious. 3. Differences launching on 32- vs 64-bit host platform. See number 2 above. 4. VS2010 needs patching: http://social.msdn.microsoft.com/Forums/en/msbuild/thread/e5900710-9849-4d10-aa28-48b734d06bf2 This is (or would be) a stopper in Brew and is my current focus. I'd like to convince the qpid build to use .NET 4.0 Tools to avoid the problem. 5. VS2008 needs upgrade to SP1. (Brew issue?) See #2 above. Command line devenv chokes on a 64-bit host while it works fine on a 32-bit host. 6. Brew-built Boost does *NOT* unpack correctly with 7-zip. Use cygwin or Git Bash tar. Note: any file named XXX.tar.gz on a windows system is usually trouble. The errors are profound: every #include of boost.anything fails in an unusual pattern. Very ugly. Mushing onward, Chuck
The WinSDK build process has improved with Brew producing usable but incomplete kits. After a few more tweaks to the canned .NET csharp projects, this may build correctly. Then there's rewrites to the Readme files and Release Notes. Trust me that I cannot honestly write the Readme files and Release Notes yet because I have not seen it work yet.
Qpid winsdk packages now support Microsoft Visual Studio 2010; all C++ and C# example applications are able to be compiled and run without exceptions. Tested on platforms: Windows XP - x86 and x64 Windows 7 - x86 and x64 Windows Server2003 - x86 and x64 Windows Server2008 - x86 and x64 Windows Server2008R2 - x64 with brokers on: Rhel 5.7 - i386 and x86_64 Rhel 6.2 - i386 and x86_64 [root@hostname ~]# rpm -qa | grep qpid qpid-cpp-client-0.14-1.el6.x86_64 python-qpid-qmf-0.14-2.el6.x86_64 qpid-java-common-0.14-1.el6.noarch qpid-cpp-server-rdma-0.14-1.el6.x86_64 qpid-tools-0.14-1.el6.noarch qpid-cpp-server-cluster-0.14-1.el6.x86_64 qpid-qmf-debuginfo-0.14-2.el6.x86_64 qpid-java-jca-0.10-11.el6.noarch qpid-java-jca-zip-0.10-11.el6.noarch ruby-qpid-0.7.946106-2.el6.x86_64 qpid-cpp-server-0.14-1.el6.x86_64 python-qpid-0.14-1.el6.noarch qpid-cpp-client-devel-0.14-1.el6.x86_64 qpid-cpp-client-ssl-0.14-1.el6.x86_64 qpid-java-client-0.14-1.el6.noarch qpid-cpp-server-ssl-0.14-1.el6.x86_64 qpid-qmf-devel-0.14-2.el6.x86_64 qpid-tests-0.14-1.el6.noarch ruby-qpid-qmf-0.14-2.el6.x86_64 rh-qpid-cpp-tests-0.14-1.el6.x86_64 qpid-cpp-server-xml-0.14-1.el6.x86_64 qpid-cpp-debuginfo-0.14-1.el6.x86_64 qpid-cpp-client-devel-docs-0.12-6.el6.noarch rh-tests-distribution-MRG-Messaging-qpid_common-1.6-70.noarch qpid-qmf-0.14-2.el6.x86_64 qpid-cpp-client-rdma-0.14-1.el6.x86_64 qpid-java-example-0.14-1.el6.noarch qpid-cpp-server-devel-0.14-1.el6.x86_64 qpid-cpp-server-store-0.14-1.el6.x86_64 Verified on packages qpid-cpp-x*-VS2010-2.2.0.1-1 --> VERIFIED
Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: Cause: Upstream project has no support for Visual Studio 2010 WinSDK. Visual Studio 2008 is hard-coded as the only version. Consequence: Visual Studio 2010 users cannot run or otherwise use MRG-Messaging WinSDK out of the box. Customers who force the Visual Studio 2008 WinSDK into their Visual Studio 2010 projects end up with processes that have simultaneously loaded two different versions of the Microsoft Visual C runtime. Fix: 1) Reorganize upstream project to separate common source files and resources from Visual Studio version-specific control files. 2) Generate Visual Studio 2010 equivalents of all Visual Studio 2008 control files. 3) Build and publish Boost compiled by Visual Studio 2010. 4) Modify all build, package, and test scripts to include both Visual Studio 2008 and 2010. Result: Customers may select the WinSDK that matches their development environment and have no issues with conflicting run-time component versions.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHSA-2012-0529.html