How to shrink the size of a WTL application? - c++

WTL applications are quite small already. However, using VS 2005 a statically linked application with WTL 9.10 weighs in at 136 kB (139,264 Bytes) for the Win32 configuration.
Looking at the executable I noticed a static import of oleaut32.dll. A cursory look with dumpbin shows one import via ordinal.
OLEAUT32.dll
4181C0 Import Address Table
41C9B8 Import Name Table
0 time date stamp
0 Index of first forwarder reference
Ordinal 277
Inspecting oleaut32.dll one finds that the export is named VarUI4FromStr.
Digging a little with IDA, I found that VarUI4FromStr was used by ATL::CRegParser::AddValue. Following the dependents from there, showed two calls in ATL::CRegParser::RegisterSubkeys.
Cross-referencing the ATL code of my Visual Studio installation with the findings, I found that the culprit was ATL::CAtlComModule. It does a lot of TypeLib registration stuff that is simply not needed for my use case.
However, the linker seems to leave all of that in, because it cannot reasonably decide to throw it out.
How can I get rid of this seemingly superfluous import?

Alas, since WTL::CAppModule derives directly from ATL::CComModule, including the atlbase.h header while having _ATL_NO_COMMODULE defined leads to an error:
Error 1 fatal error C1189: #error : WTL requires that _ATL_NO_COMMODULE is not defined $(ProjectDir)\wtl\Include\atlapp.h 33
The actual culprit that ultimately pulls in ATL::CComModule is, however, ATL::CAtlComModule. So our goal is to get rid of both of them.
We'll try to trick atlbase.h into excluding all the TypeLib registration code by defining _ATL_NO_COMMODULE anyway, but undefining it right after we're done including it. This way atlapp.h and other WTL headers won't "notice".
#define _ATL_NO_COMMODULE
#include <atlbase.h>
#undef _ATL_NO_COMMODULE
#include <atlapp.h>
Obviously that gets us into some trouble:
1>atlapp.h(1515) : error C2039: 'CComModule' : is not a member of 'ATL'
1>atlapp.h(1515) : error C2504: 'CComModule' : base class undefined
1>atlapp.h(1524) : error C2653: 'CComModule' : is not a class or namespace name
1>atlapp.h(1543) : error C2653: 'CComModule' : is not a class or namespace name
1>atlapp.h(1625) : error C3861: 'GetModuleInstance': identifier not found
1>atlapp.h(1784) : error C2653: 'CComModule' : is not a class or namespace name
1>atlapp.h(1806) : error C2065: 'm_nLockCnt' : undeclared identifier
However, it looks like we should be able to fix this handful of errors quickly.
First of all let's check where ATL::CComModule comes from: it's declared and defined in atlbase.h. We can surely declare our own class and squeeze it in between #include <atlbase.h> and #include <atlapp.h> (see above).
Let's start with the basics, based on what can be found in atlbase.h:
namespace ATL
{
class CComModule : public CAtlModuleT<CComModule>
{
public:
CComModule() {}
};
};
Now we get a different set of errors:
1>atlapp.h(1524) : error C2039: 'Init' : is not a member of 'ATL::CComModule'
1> stdafx.h(31) : see declaration of 'ATL::CComModule'
1>atlapp.h(1625) : error C3861: 'GetModuleInstance': identifier not found
Excellent, so we're in fact only missing two more class functions: GetModuleInstance and Init. Let's pull those in as well. For good measure we'll also add GetResourceInstance:
namespace ATL
{
class CComModule : public CAtlModuleT<CComModule>
{
public:
CComModule() {}
HINSTANCE GetModuleInstance() throw() { return _AtlBaseModule.m_hInst; }
HINSTANCE GetResourceInstance() throw() { return _AtlBaseModule.m_hInstResource; }
HRESULT Init(_ATL_OBJMAP_ENTRY*, HINSTANCE, const GUID*) throw() { return S_OK; }
};
};
A short test proves that this is working fine. And the oleaut32.dll import is gone along with three more imports from ole32.dll. Great success!
And as a result we have saved 12 kB on the executable size.
Do you know other cool tricks to shrink WTL application size?
IMPORTANT
Note that depending on the features of ATL::CComModule which your code uses, you may have to fall back to using the original. The only other alternative is to extend the above mock version of ATL::CComModule to fix any compilation errors you may run into.
CAUTIONARY NOTE
I have not tested this extensively yet and I'll report back (by editing this answer) if I run into any trouble. However, from looking at it in both the ATL and WTL code as well as in the IDA database prior to my changes, I think this is a safe change.
Bonus trick
You may also use the 6001.18002 standalone WDK (for Vista SP1), which supports to target Windows 2000 (SP4) and newer. It includes ATL 7.0 and is therefore suited to build ATL+WTL applications.
To do that you just need to add the following two lines to your sources file:
USE_STATIC_ATL=1
ATL_VER=70
Thanks to the WDK, which uses msvcrt.dll, a system DLL, as its default (multithreaded dynamically linked) C runtime, you can then shrink the executable size further by linking dynamically to the C runtime. And in this case, since that particular C runtime is a system DLL (starting with Windows 2000), you can rest assured that it will work.
All of that taken into account you can build standard Windows applications (GUI or console) and DLLs that are really small.
Here is an example sources file which you can use as a template:
# Name of the program
TARGETNAME=progname
# Prefix used for the intermediate/output paths (e.g. objfre_w2k_x86)
TARGETPATH=obj
# A program, not a driver or DLL or static lib
TARGETTYPE=PROGRAM
# windows == GUI, console == Console, native == no subsystem ...
UMTYPE=windows
# Use Unicode ("wide char") instead of ANSI
UNICODE=1
# By default the WDK build treats warnings as errors - this turns it off
BUILD_ALLOW_ALL_WARNINGS=1
# Link dynamically to msvcrt.dll
USE_MSVCRT=1
# Don't link against any of the ATL DLLs
USE_STATIC_ATL=1
# In the 7600.16385.1 WDK you can use 70 as well, which translates to 71
ATL_VER=70
USE_NATIVE_EH=1
# RTTI is required for some ATL/WTL features
USE_RTTI=1
# GUI programs require these entry points
!IF defined(UNICODE) && $(UNICODE)
UMENTRY=wwinmain
C_DEFINES=$(C_DEFINES) /DUNICODE /D_UNICODE
!ELSE
UMENTRY=winmain
C_DEFINES=$(C_DEFINES) /DMBCS /D_MBCS
!ENDIF
# Include folders
INCLUDES=$(DDK_INC_PATH);$(CRT_INC_PATH);$(SDK_INC_PATH);wtl\Include
# Libraries to link to, not just import libraries
TARGETLIBS=\
$(SDK_LIB_PATH)\kernel32.lib \
$(SDK_LIB_PATH)\user32.lib \
$(SDK_LIB_PATH)\Comctl32.lib \
# Give source files (also resources and .mc) in the current or parent directory
SOURCES=...
The 7600.16385.1 standalone WDK also works for this. The WDKs starting from the Windows 8 WDK now require a Visual C++ into which they can be integrated. This also leads to the binaries requiring the respective C runtime version instead of the msvcrt.dll from prior WDK versions.

Related

Q_DECLARE_INTERFACE for plugin creation throws errors all over

Environment:
Framework: Qt 5.12.9
Compiler: MSVC 15.9.28307.1234 (x64)
Debugger: CDB 10.017763.132 (x64)
Standard: C++11
Editor: Qt Creator 4.12.2
OS: Win10 Enterprise 1809
I want to develop an application that can be expanded through plug-ins. Therefore I created a standard library project where I want to define the plug-in interfaces. This library should then be consumed by the main application and its plug-ins.
I read about the Qt plug-in system on the official websites and sought help by duckduckgo-ing, but I'm stuck with these following errors:
vccplugin.h:16:32: error: expected parameter declarator
vccplugin.h:14:23: note: expanded from macro 'VccPlugin_iid'
vccplugin.h:16:32: error: expected ')'
vccplugin.h:14:23: note: expanded from macro 'VccPlugin_iid'
vccplugin.h:16:20: note: to match this '('
vccplugin.h:16:1: error: C++ requires a type specifier for all declarations
Build Issue: C2059: syntax error: 'string'
This is the code:
#ifndef VCCPLUGIN_H
#define VCCPLUGIN_H
#include "VccPluginInterface_global.h"
class VCCPLUGININTERFACE_EXPORT VccPlugin
{
public:
VccPlugin();
~VccPlugin();
void DoeEenTwuk();
};
#define VccPlugin_iid "automation.general.vcc.interface"
Q_DECLARE_INTERFACE(VccPlugin, VccPlugin_iid);
#endif // VCCPLUGIN_H
Also note, I have little experience in both C++ and Qt.
Any help very appreciated,
thanks
I have found the issue. The problem is that the compiler couldn't find the macro, so all I had to add was:
#include <QtPlugin>
Since Q_DECLARE_INTERFACE is defined in QtPlugin. Your example didn't import QtPlugin but was probably imported implicit by another import, probably QMainWindow.
It would have been simpler if I got an error like: "Could not find symbol Q_DECLARE_INTERFACE" if you ask me. Especially since I'm rather blue in this topic.
Thanks for your support #NgocMinhNguyen and others

ISampleGrabber undeclared identifier

I'm trying to execute a code generated by graphEditPlus (using VS2010) but having a trouble with the following line:
CComQIPtr<ISampleGrabber, &IID_ISampleGrabber> pSampleGrabber_isg(pSampleGrabber);
where the errors are:
error C2065: 'ISampleGrabber' : undeclared identifier
error C2065: 'IID_ISampleGrabber' : undeclared identifier
error C2514: 'ATL::CComQIPtr' : class has no constructors
I tried downloading different versions of Windows SDK (V7.1, V6.0A, V5) and set the include / lib paths but still having the same problem!
Is the SampleGrabber still being supported? Mainly, the SampleGrabber is used in my code to grab frames from a video capturing source...
Thanks for your assistance...
Microsoft deprecated Sample Grabber and the entire DES API, however you if you import the type library, or just copy the declarations into your project - the component is still usable except some very latest OS releases (Windows Server 2008?) where it is completely gone and you might need another solution such as building your own from earlier SDK samples.
See ISampleGrabber deprecated: where can I find alternatives? for more information.
See also RenderWmvVideo.cpp with code fragment to copy/paste and re-add the declarations to your project (#pragma section at the top of the file):
#pragma region Windows SDK Tribute, qedit.h
struct __declspec(uuid("0579154a-2b53-4994-b0d0-e773148eff85"))
ISampleGrabberCB : IUnknown
{
...
#pragma endregion

Visual Studio C++ NPAPI plugin with Twain support

I want to make a Google Chrome plugin that use Twain to remote control a Digital Camera.
I want this to run on Windows and I'm using Visual Studio Express 2012 C++.
I have this sample for NPAPI and this sample of CppWrapper for Twain which has 3 interesting files (TwainCpp.cpp TwainCpp.h twain.h)
Before doing anything, I want to merge these two projects.
First step: putting twain.h in the npsimple project which failed, twain.h errors caught.
Second step: putting CppTwain in npsimple, which also failed because twain.h "contains" errors.
Problem is that when I create an empty project, and put twain.h in it, there is no error! So I tried to put npsimple files in that empty project, and this time I get error from npsimple files..
Error type :
I have this code in twain.h :
#ifdef _MSWIN_
typedef HANDLE TW_HANDLE;
typedef LPVOID TW_MEMREF;
and I get plenty of errors like :
error C2146: syntax error : missing ';' before identifier 'TW_HANDLE'
How can I merge these projects?
HANDLE is an unspecified type because you don't include anything that is specificing it. You'll want to include windows.h.
Obviously there is no error when you add only the twain.h header file to the empty project - you haven't added any sources to compile, hence there can be no compilation errors.

LNK2019 unresolved external symbol NtOpenFile

I am facing linker error with my code. I am trying to compile with Visual Studio command Prompt (2010) in Win-7 X64 bit m/c.
The error which i see are as below.
dust2.obj
dust2.obj : error LNK2019: unresolved external symbol _NtOpenFile#24 referenced
in function _main
dust2.obj : error LNK2019: unresolved external symbol _RtlAnsiStringToUnicodeStr
ing#12 referenced in function _main
dust2.obj : error LNK2019: unresolved external symbol _RtlInitAnsiString#8 refer
enced in function _main
dust2.exe : fatal error LNK1120: 3 unresolved externals
The simplified version of my code is like this:
#include <windows.h>
#include <iostream>
#include <Winternl.h>
using namespace std;
int main()
{
NTSTATUS Status;
OBJECT_ATTRIBUTES Obja;
HANDLE SourceFile;
PUNICODE_STRING PathName=0;
PANSI_STRING p_path=0;
const char* ccp_path = "D:\\txt.txt";
RtlInitAnsiString( p_path,ccp_path );
RtlAnsiStringToUnicodeString( PathName, p_path, true );
IO_STATUS_BLOCK IoStatusBlock;
wprintf(L"%s", PathName->Buffer);
InitializeObjectAttributes(
&Obja,
PathName,
OBJ_CASE_INSENSITIVE,
NULL,
NULL
);
Status = NtOpenFile(
&SourceFile,
FILE_LIST_DIRECTORY | FILE_READ_EA | FILE_READ_ATTRIBUTES,
&Obja,
&IoStatusBlock,
FILE_SHARE_READ | FILE_SHARE_WRITE,
FILE_DIRECTORY_FILE | FILE_OPEN_FOR_BACKUP_INTENT | FILE_OPEN_REPARSE_POINT
);
if(SourceFile == INVALID_HANDLE_VALUE){
printf("\nError: Could not open file\n");
return 0;
}
cout<<endl<<endl;
system("pause");
return 0;
}
In another post in this forum the solution of these kind of problem was mention to include a #pragma.
I tried this solution by adding #pragma like this
#pragma comment(lib, "ntdll")
but on compilation i see another error that says "LINK : fatal error LNK1104: cannot open file 'ntdll.lib'".
I will much appreciate your help to resolve this problem. Thanks..
Can't let this question go unanswered like this. Because although the remark by Mladen is largely right for this particular native API, the whole topic deserves an in-depth discussion.
Preliminary cautionary note
Up front I should note that in many many cases it is neither desirable nor necessary to use one of the native API functions on Windows. However, there are a few cases where the Win32 API doesn't provide the means to query information or even manipulate data and so on. One such case would be several of the information classes available for NtQueryInformationFile/ZwQueryInformationFile.
One good example is the enumeration of alternate data streams on files and directories, which can be done using the Win32 API, in particular by using the backup APIs, but will require special privileges in that case. Not so if you resort to the native API. The same used to be true for hard links until Windows 2000, which introduced CreateHardLink to the Win32 API. Although in this particular case if you knew your way around you could have used MoveFileEx with MOVEFILE_CREATE_HARDLINK ever since it got introduced (although Microsoft still as of this writing marks it as Reserved for future use ... meh).
The canonical books about the native API are these two:
Windows NT/2000 Native API Reference, Gary Nebbett
Undocumented Windows 2000 Secrets: A Programmer's Cookbook, Sven B. Schreiber (free version from the author's website here)
... there are more, including one that discusses NT 4 and preceded Nebbett's book. But Nebbett's book used to start the hype around the native API, much like Hoglund's book started the hype around Windows rootkits. Not a reference regarding the Native API topic but still good:
Windows Internals, Mark Russinovich et. al.
Check out this website for a huge number of native API functions "documented":
http://undocumented.ntinternals.net/
So remember: the inherent risk when using these functions is that they go away in a future Windows version or their semantics change without prior notice. So be careful when you use them, if you use them.
On to glory ...
How to call native API functions
Actually there are two ways to call these functions. Microsoft was forced to disclose some of the native API functions in one of the antitrust law suits some years ago. These were shoved into winternl.h of the SDK. Microsoft expresses it thus:
The NtOpenFile documentation is provided for the sake of full API
coverage. NtOpenFile is equivalent to the ZwOpenFile function
documented in the DDK. For more information on the ZwOpenFile and
related functions, go to http://msdn.microsoft.com/library. In the
left-hand pane, click Windows Development, then click Driver
Development Kit.
However, there is no accompanying ntdll.lib file in the SDK. Microsoft suggests you link those functions dynamically (second option below).
You have several options:
The most common is to do as you did. But the ntdll.lib import library is only part of the WDKs, not the DDKs.
Use GetProcAddress to find the function pointer and call it. GetModuleHandle is sufficient for the Win32 subsystem since every Win32 program is guaranteed to have loaded ntdll.dll.
Method 1: ntdll.lib
If you have the DDK/WDK - for Driver Development Kit and Windows Driver Kit respectively - you get a full set of ntdll.lib files already. On my system (Windows 7 WDK 7600.16385.1):
C:\WINDDK\7600.16385.1\lib\win7\amd64\ntdll.lib
C:\WINDDK\7600.16385.1\lib\win7\i386\ntdll.lib
C:\WINDDK\7600.16385.1\lib\win7\ia64\ntdll.lib
C:\WINDDK\7600.16385.1\lib\wlh\amd64\ntdll.lib
C:\WINDDK\7600.16385.1\lib\wlh\i386\ntdll.lib
C:\WINDDK\7600.16385.1\lib\wlh\ia64\ntdll.lib
C:\WINDDK\7600.16385.1\lib\wnet\amd64\ntdll.lib
C:\WINDDK\7600.16385.1\lib\wnet\i386\ntdll.lib
C:\WINDDK\7600.16385.1\lib\wnet\ia64\ntdll.lib
C:\WINDDK\7600.16385.1\lib\wxp\i386\ntdll.lib
Create your own makeshift ntdll.lib
Otherwise you have to generate ntdll.lib yourself from the output of dumpbin (or by other means that allow to parse the exports of the DLL) which you can then output into a module definition file from which you can build an export .lib. Sounds convoluted? Not so much, let's see ;)
Using Ero Carrera's pefile Python module, we can do this:
import os, re, sys
from os.path import basename, dirname, join, realpath
try:
import pefile
except ImportError:
try:
sys.path.append(join(realpath(dirname(__file__)), "pefile"))
import pefile
except:
raise
def main(pename):
from pefile import PE
print "Parsing %s" % pename
pe = PE(pename)
if not getattr(pe, "DIRECTORY_ENTRY_EXPORT", None):
return "ERROR: given file has no exports."
modname = basename(pename)
libname = re.sub(r"(?i)^.*?([^\\/]+)\.(?:dll|exe|sys|ocx)$", r"\1.lib", modname)
defname = libname.replace(".lib", ".def")
print "Writing module definition file %s for %s" % (defname, modname)
with open(defname, "w") as f: # want it to throw, no sophisticated error handling here
print >>f, "LIBRARY %s\n" % (modname)
print >>f, "EXPORTS"
numexp = 0
for exp in [x for x in pe.DIRECTORY_ENTRY_EXPORT.symbols if x.name]:
numexp += 1
print >>f, "\t%s" % (exp.name)
print "Wrote %s with %d exports" % (defname, numexp)
print "\n\nUse this to create the export lib:\n\tlib /def:%s /out:%s" % (defname, libname)
if __name__ == '__main__':
if len(sys.argv) != 2:
sys.exit("ERROR:\n\tSyntax: fakelib <dllfile>\n")
sys.exit(main(sys.argv[1]))
A sample output of running this script (when named fakelib.py) would be:
> fakelib.py ntdll.dll
Parsing ntdll.dll
Writing module definition file ntdll.def for ntdll.dll
Wrote ntdll.def with 1984 exports
Use this to create the export lib:
lib /def:ntdll.def /out:ntdll.lib
Then we run the command as given on the last line. It is even better to give the /machine: parameter, of course. This is left as an "exercise" (*cough* *cough*) to the reader. The output with VS 2012 will be:
> lib /def:ntdll.def /out:ntdll.lib
Microsoft (R) Library Manager Version 11.00.51106.1
Copyright (C) Microsoft Corporation. All rights reserved.
LINK : warning LNK4068: /MACHINE not specified; defaulting to X86
Creating library ntdll.lib and object ntdll.exp
Congratulations. You can now use the ntdll.lib created by Microsoft's own lib.exe to statically import from ntdll.dll, even without having the "real" (original) .lib on your system.
Adjust the path and file names to your needs and tastes.
When using MinGW
Damon pointed out in a comment that the toolchain included with MinGW contains a tool gendef that can do the job of above Python script and that the output can be fed to dlltool.
Issues
The above method works perfectly when targeting x64 (64-bit), but for x86 (32-bit) I have encountered linker errors at times.
The issue is that the name decoration for __stdcall differs between x64 and x86. The former doesn't really use the same __stdcall as x86 and therefore just prepends an underscore. However, the latter also appends a the number of arguments times sizeof(void*) (i.e. 4). So for one argument the decorated function name for a function int __stdcall foo(int); becomes _foo#4.
This KB article from Microsoft outlines a way to get around the issue.
Method 2: dynamically imported, using GetProcAddress
Documentation in MSDN states (for NtOpenFile):
Note that the DDK header file Ntdef.h is necessary for many constant
definitions as well as the InitializeObjectAttributes macro. The
associated import library, Ntdll.lib is also available in the DDK. You
can also use the LoadLibrary and GetProcAddress functions to
dynamically link to Ntdll.dll.
Declare a function type, e.g. here we declare the type TFNNtOpenFile suitable in your case:
typedef NTSTATUS (NTAPI *TFNNtOpenFile)(
OUT PHANDLE FileHandle,
IN ACCESS_MASK DesiredAccess,
IN POBJECT_ATTRIBUTES ObjectAttributes,
OUT PIO_STATUS_BLOCK IoStatusBlock,
IN ULONG ShareAccess,
IN ULONG OpenOptions
);
... and then retrieve the function pointer and call it:
TFNNtOpenFile pfnNtOpenFile = (TFNNtOpenFile)GetProcAddress(GetModuleHandle("ntdll.dll"), "NtOpenFile");
status = pfnNtOpenFile(...); // can't be bothered to type out all parameters ;)
an alternative way of retrieving the function pointer could be this one:
static NTSTATUS (NTAPI *NtOpenFile)(
OUT PHANDLE,
IN ACCESS_MASK,
IN POBJECT_ATTRIBUTES,
OUT PIO_STATUS_BLOCK,
IN ULONG,
IN ULONG
);
(FARPROC)&NtOpenFile = GetProcAddress(GetModuleHandle("ntdll.dll"), "NtOpenFile");
which could be condensed even further by using the preprocessor stringification operator (#). The choice is yours.
These functions cannot be called directly because they belong to internal API and are not exposed through any of the libraries. You need to obtain addresses of these function using GetProcAddress.
For more information look here.

Custom attributes are not consistent?

i have converted a C++ library to managed and get the following error on this code line:
std::ifstream fin(filename, std::ifstream::in);
Errors:
Error 30 error LNK2022: metadata operation failed (80131195) : Custom attributes are not consistent: (0x0c0003b5). C:\Users\Freeman\Documents\Visual Studio 2010\Projects\testsharp1\cpp1\MSVCMRTD.lib(locale0_implib.obj)
Error 32 error LNK2034: metadata inconsistent with COFF symbol table: symbol '??0_Container_base12#std##$$FQAE#XZ' (06000493) has inconsistent metadata with (0A000075) in MSVCMRTD.lib(locale0_implib.obj) C:\Users\Freeman\Documents\Visual Studio 2010\Projects\testsharp1\cpp1\LINK
Error 59 error LNK2034: metadata inconsistent with COFF symbol table: symbol '?memcpy##$$J0YAPAXPAXPBXI#Z' (060004DD) has inconsistent metadata with (0A0003E3) in MSVCMRTD.lib(locale0_implib.obj) C:\Users\Freeman\Documents\Visual Studio 2010\Projects\testsharp1\cpp1\LINK
Error 60 error LNK1255: link failed because of metadata errors C:\Users\Freeman\Documents\Visual Studio 2010\Projects\testsharp1\cpp1\LINK
How to fix that or how to change that code line without having to change the rest of the code?
Essentially, you're compiling your managed code which includes the <fstream> header. That means that all declarations from <fstream> are compiled as if they're managed, too. Yet the CRT DLL contains unmanaged versions of <fstream>.
At link time, this is detected when the import lib MSVCMRTD.lib contains the unmanaged std::_Container_base class, but your .obj files need a managed std::_Container_base.
(The _C tells us it's an implementation helper class).
I know this question is old, but after 1 week struggling to solve this I feel committed to post the solution I found to whoever could be fighting with a similar error.
In my case I'd two projects, one unmanaged with std's all over the place (list, vectors and queues, this is a project which should work on linux too so I cannot use .net collections), and pure standard C++ code, on the second project I create a managed project to wrap this classes to be used in .net projects, I was using Visual Studio 2010, trying to use framework 2.0, unfortunatelly VS 2010 does not have a nice support to VC++, and I tried everything to force it to use 2.0, without success, everytime I compiled I got the same annoying message "Inconsistent blah".
I installed VS 2008, ported the projects to 2008 and voila! everything worked in 10 mins, I spend 1 week trying to solve this in VS 2010 and 2008 did the trick.
I hope this might save a lot of hours trying to solve something that appears to be unsolvable on VS 2010.