locked
References to WinRT Componant DLL projects written in Native ISO Standard C++.

    Question

  • I have  a Componant DLL written in ISO Standard C++. 

    This project is part of a solution with a Metro style App.

    When I add a reference to the Componant DLL, the Package Builer looks for the Winmd file and cant find it.

         2>_GenerateProjectPriFile:
         2>  MyProj -> resources.pri
         2>C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\AppxPackage\Microsoft.AppXPackage.Targets(652,9): error APPX1703: The file 'MyComponantDll.winmd' is not a winmd file, or an error occured when loading it.

    If I force the output from the midl stage on the Componant Dll Project.  Then It will finish packaging, as long as the start up project is not dirty.  If the startup project becomes dirty then the MyComponantDll.winmd file gets erased during the clean stage of the build process.

    Since the Startup project has a dependency on the Componant DLL, the Dll gets built, then the Startup gets built.  This erases the file needed to complete the build.

    I can add a C++/CX Componant DLL and this does not happen.  Mixing the settings in the VCProj files between the C++/CX project and the ISO Standard C++ project does not resolve this issue.

    It seems to be a bug.


    This is my signature.

    Thursday, April 19, 2012 12:06 AM

Answers

  • There are a number of issues here and one of which is certainly a bug in the Visual Studio Tool Chain.

    The first issue is that the output for the project was set to the output for the Solution.  Building the solution Erases items in the Solution Output directory which eliminates the files required for a complete build.  The fix for this is to Set the output directory for the Componant DLL to something other than the Solution Output directory.

    The second issue is that when you add a reference to the startup project, to the Componant DLL, the metadata file looked for is in the form of $(ProjectName).winmd.  There dfoes not seem to be a way to change this.  This is a problem becuase the .winmd file is not called $(ProjectName).winmd.  The Winmd file is generated to be the topmost Namespace specified in the IDL file followed by ".winmd".  The only time this works properly is when the topmost namespace matches the $(ProjectName).  This is most likely a bug.

    The third and final requirement is that the Class definition contains the InspectableClass Macro with the runtimeClassName set to the Proper fully qualified namespace resolution for the activatable class. 


    This is my signature.

    Thursday, April 19, 2012 8:47 PM

All replies

  • You've lost me. The only component project is a 'WinRT Component DLL'. If you create this project type, it creates a winmd file which you can then add a reference to.

    How do you add a reference to a dll? References should be to .winmd files. Exactly what project type is your ISO Standard C++ code? How are you getting a MyComponentDll.winmd file out of a non-C++/CX project?

    A plain old standard win32 dll should be referenced in the same manner as before - include the right header files and then link with the import .lib file.

    -Steve

    Thursday, April 19, 2012 12:39 AM
    Moderator
  • I have a standard Project for building a DLL.

    According to Herb Sutter this is not an issue:

           http://channel9.msdn.com/Events/BUILD/BUILD2011/TOOL-532T

    This is what WRL is for, there is actually an entire api for this:

          http://msdn.microsoft.com/en-us/library/br230382(VS.110).aspx

    And here are some reason why you would do this instead of using Microsoft's Compiler Specific Componant Extensions:

          http://msdn.microsoft.com/en-us/library/hh438466(VS.110).aspx

    The Winmd file is generated by the MIDL compiler. 

    I hope you are not lost at this point.

    I just want to indicate one more time, that the DLL and the WinRT Componant are not the issue.  These work just fine.

    The issue is that Right clicking on the Startup Project in the Solution explorer, selecting References.., Clicking "Add New Reference", Choosing Solution in the laft panel, and selecting the project titled "MyComponantDll".  Should add the winmd output from that project to the application package.  This does not happen. 

    A reference to the winmd is added then you get an error when building that the file can not be found, or that there is an issue loading it.  When you check the path you will see that the file is not present.  If you add the file manually then rebuild it loads fine, it runs fine, The packe is installed, and the componants in the dll can be referenced, created and used.

    Clearly the issue is with some setting in the visual studio project that is preventing the proper behavior.  Unless Microsoft just plain does not support ISO Standard C++ projects.

    Dan -


    This is my signature.

    Thursday, April 19, 2012 3:34 PM
  • There are a number of issues here and one of which is certainly a bug in the Visual Studio Tool Chain.

    The first issue is that the output for the project was set to the output for the Solution.  Building the solution Erases items in the Solution Output directory which eliminates the files required for a complete build.  The fix for this is to Set the output directory for the Componant DLL to something other than the Solution Output directory.

    The second issue is that when you add a reference to the startup project, to the Componant DLL, the metadata file looked for is in the form of $(ProjectName).winmd.  There dfoes not seem to be a way to change this.  This is a problem becuase the .winmd file is not called $(ProjectName).winmd.  The Winmd file is generated to be the topmost Namespace specified in the IDL file followed by ".winmd".  The only time this works properly is when the topmost namespace matches the $(ProjectName).  This is most likely a bug.

    The third and final requirement is that the Class definition contains the InspectableClass Macro with the runtimeClassName set to the Proper fully qualified namespace resolution for the activatable class. 


    This is my signature.

    Thursday, April 19, 2012 8:47 PM
  • Yes, I understand what WRL is and how it integrates with WinRT. Now that you've informed us that you are using WRL I'm closer to not being lost. However, I don't know what an ISO Standard C++ project is. Generally, we refer to project types by their titles in the project wizard, so I'm assuming what you are calling the ISO Standard C++ project is the C++ 'Win32 Project' type with Application Type set to DLL in the project application settings. Of course you could be referring to an ATL Project on which you've heavily modified the IDL and C++ and project settings as this also produces ISO C++ code. In either case, .winmd files and WRL components are not the default outputs so you've no doubt heavily modified whatever default project type you started with.

    We're still building terminology here, but I'm going to call what you are building as a C++ WRL Component. There is no project type currently in the product which produces a C++ WRL Component as it's output so it would be helpful if you could give us a step-by-step description of what project type you started with and how you've modified it to create the WRL Component project. Is it possible you've based it off of this sample - http://code.msdn.microsoft.com/windowsapps/Windows-Runtime-Component-e3e1e38d?

    In lieu of describing repro steps to get to your errors, if you'd like to send me the solution at shorne at microsoft dot com, I'll be happy to take a look at it.

    -Steve

    Thursday, April 19, 2012 9:27 PM
    Moderator
  • Hi Steve,

     

    The International Organization for Standardization, or ISO, approved C++11 in August of 2011.

     

    You should probably be aware that this does not include the Microsoft Componant Extensions, commonly refered to as "CX".

    The third link above should have given you some idea of what I have done.  Did you think there was some other way to use WRL instead of CX ?

    In any case.  I have resolved the problem, as documented in my previous post, and filed a bug on the Issue with the application packager.


    This is my signature.

    Friday, April 20, 2012 4:19 PM