locked
Windows Store apps with native calls

    Question

  • Hello, 

    Is it possible to make Windows Store application, with native dlls, that will be called from .Net code?


    Best regards, 

    Moskvichev Andrey V.

    Sunday, January 27, 2013 11:13 AM

Answers

  • Hi Moskvichev,

    Whether your code is .Net or native does not affect this. Windows Store apps have direct access only to their install and application data directories. The security system will prevent them from directly reading any other path. Your app can call fopen, etc. to read files from these directories, but not from others. As noted, using synchronous API is not recommended on your UI thread, but you can use these on worker threads.

    Apps can get access to other locations with permission from the user (either via declared capabilities or via the FilePicker). In these cases a broker app will open the file and provide its contents as a stream through the StorageFile object. Your app can read or write the stream, but cannot directly access the file itself. There may not even be a file system file. The user can select a StorageFile from another app.

    You can create a native C or C++ DLL and include it in your AppxPackage. Your .Net for Windows Store app can p-invoke into this DLL through the normal p-invoke system, but of course your DLL can use only the API and parts of the C-runtime which are permitted for Windows Store apps (see the links Raffaele provided). As Jesse mentioned, you can also wrap your DLL in a Windows Runtime Component which protect it into .Net languages in a more natural way, but that is not required and may be less efficient than p-invoke.

    As far as how to deal with your document parsing code, it depends a lot on how well factored the code is. If you can factor out the file opening and reading functions and provide a stream to the actual parsing code then updating it to work properly in a Windows Store app should be fairly straightforward. If the file code is well mixed in with the parsing code then this will be more difficult. In that case you may want to consider reading and writing only from the application data directories. You can add a small wrapper layer to copy files chosen with the FileOpenPicker to your ApplicationData.TemporaryFolder and then use C runtime calls to read it from there.

    If at all possible, I would try to refactor the code to accept streams rather than making an extra copy.

    --Rob

    Tuesday, January 29, 2013 2:47 AM
    Owner

All replies

  • Yes, you can create native Windows Runtime components using C++.
     
    There are two options to build these "special" dlls:
    - the easy one is to use C++/CX that is a C++ dialect which generate
    pure native code. This dialect was created to easily deals with the
    rules of WinRT. For example a Button^ (handle to a button) is a smart
    pointer which calls the necessary infrastructure (QueryInterface,
    AddRef and Release) for you.
    - the complex one is using WRL which use plain standard C++11 language.
    The downside of this approach is to use ComPtr<Button> in place of the
    aforementioned handle.
    There are obviously more constructs that are easier in C++/CX. On msdn
    you will find relevant example/docs.
    The WRL template for Visual Studio 2012 can be downloaded using the
    extension manager.
     
    Visual Studio will create in both cases a dll and a winmd file
    (metadata).
    Personally I would suggest the first option.
     
    Once you compile the C++ solution, you create a C# project and
    reference the winmd file into the C# project references. From now on
    you can use your C++ component as it was part of the WinRT library.
     
    BTW it's also possible the opposite even if there pros and cons must be
    carefully evaluated.
     --
    Raffaele Rialdi  http://www.iamraf.net
    Microsoft MVP profile
     

    Raffaele Rialdi [MVP] My articles and videos: http://www.iamraf.net Italian blog: http://blogs.ugidotnet.org/raffaele
    Sunday, January 27, 2013 3:23 PM
  • Hi,

    You can create a C++/CX component dll, and use this dll in .NET Windows Store App.

    Please follow this document to create such this component
    http://msdn.microsoft.com/en-us/library/windows/apps/xaml/hh441569.aspx

    The components should be written with C++/CX, not all native C++.

    Best regards,
    Jesse


    Jesse Jiang
    MSDN Community Support | Feedback to us
    Develop and promote your apps in Windows Store
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Monday, January 28, 2013 6:54 AM
  • Thanks for your answers. 

    I can write my app in pure C#, but here is problem, that it uses some components written in C (even not C++).

    Is there any way to port existing C code to work with WinRT (now it uses std c runtime to talk with system)?

    Best regards, 

    Moskvichev Andrey V.

    Monday, January 28, 2013 7:16 AM
  • http://msdn.microsoft.com/en-us/library/windows/apps/xaml/jj606124.aspx, on this page i found info that fopen, open and etc file IO funcs, are not recommended.

    What it means? Can i use them?

    Best regards, 

    Moskvichev Andrey V.

    Monday, January 28, 2013 7:28 AM
  • Yes, You cannot these API in Windows Store. Even though you can pass the complier, but it will failed in WACK test. It means that you cannot upload your App to Windows Store.

    There is no directly way to use native dll, especially it use API which is not supported in Windows Store. We need to rewrite these part with C++/CX.
     
    Best regards,
    Jesse


    Jesse Jiang
    MSDN Community Support | Feedback to us
    Develop and promote your apps in Windows Store
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Monday, January 28, 2013 7:40 AM
  • I strongly suggest to understand the platform architecture first.
    There are good reasons for not exposing certain apis.
    For example the apis which could take more than 50ms are excluded and
    replaced with a different asynchronous api. Or other apis which could
    break the sandbox process ...
    In most of the cases understanding the architecture give the answer
    even without reading the note on msdn.
     
    --
    Raffaele Rialdi  http://www.iamraf.net
    Microsoft MVP profile
     

    Raffaele Rialdi [MVP] My articles and videos: http://www.iamraf.net Italian blog: http://blogs.ugidotnet.org/raffaele
    Monday, January 28, 2013 7:59 AM
  • Thank you again.

    From http://msdn.microsoft.com/en-us/library/windows/apps/xaml/hh449422.aspx:

    When called from a Windows Store app, CreateFile2 is simplified. Only files or directories inside theApplicationData.LocalFolder or Package.InstalledLocation directories or may be opened. Opening named pipes or mailslots or creating encrypted files (FILE_ATTRIBUTE_ENCRYPTED) are also not supported.

    As i understand, i can only open files in my app's directory.

    I there any way to overcome this constraint, and open a file, from any location? 

    Best regards, 

    Moskvichev Andrey V.

    Monday, January 28, 2013 8:58 AM
  • I'm understanding why it's made. 

    But, i must be sure, that my project is applicable for Windows Store. 

    Best regards, 

    Moskvichev Andrey V.


    Monday, January 28, 2013 10:41 AM
  • Due to the API restrictions, it can be quite hard to tell without
    looking at the code.
     
    Here you can find the list of the native API (Win32 and COM) that are
    available in the Windows Store context:
     --
    Raffaele Rialdi  http://www.iamraf.net
    Microsoft MVP profile
     

    Raffaele Rialdi [MVP] My articles and videos: http://www.iamraf.net Italian blog: http://blogs.ugidotnet.org/raffaele
    Monday, January 28, 2013 7:08 PM
  • Thanks for information. 

    A brief description of my project:

    It's a document viewer app. Document format parsing code is made in C.

    I want to make GUI in C#/XAML and link it with native part. And make it available in Windows Store.

    Rewriting parsing part of code in .Net is not possible.

    http://msdn.microsoft.com/en-us/library/windows/apps/hh464936.aspx#VideosLibrary

    I read about capabilities. But, the following is still not clear for me.

    If i declare documentsLibrary in the manifest, can i open files in docs folder from native code? Or i can open them only from .Net?

    The same question about FileOpenPicker. Can i open file chosen by user from native code? 

    Best regards, 

    Moskvichev Andrey V.


    Tuesday, January 29, 2013 1:43 AM
  • Hi Moskvichev,

    Whether your code is .Net or native does not affect this. Windows Store apps have direct access only to their install and application data directories. The security system will prevent them from directly reading any other path. Your app can call fopen, etc. to read files from these directories, but not from others. As noted, using synchronous API is not recommended on your UI thread, but you can use these on worker threads.

    Apps can get access to other locations with permission from the user (either via declared capabilities or via the FilePicker). In these cases a broker app will open the file and provide its contents as a stream through the StorageFile object. Your app can read or write the stream, but cannot directly access the file itself. There may not even be a file system file. The user can select a StorageFile from another app.

    You can create a native C or C++ DLL and include it in your AppxPackage. Your .Net for Windows Store app can p-invoke into this DLL through the normal p-invoke system, but of course your DLL can use only the API and parts of the C-runtime which are permitted for Windows Store apps (see the links Raffaele provided). As Jesse mentioned, you can also wrap your DLL in a Windows Runtime Component which protect it into .Net languages in a more natural way, but that is not required and may be less efficient than p-invoke.

    As far as how to deal with your document parsing code, it depends a lot on how well factored the code is. If you can factor out the file opening and reading functions and provide a stream to the actual parsing code then updating it to work properly in a Windows Store app should be fairly straightforward. If the file code is well mixed in with the parsing code then this will be more difficult. In that case you may want to consider reading and writing only from the application data directories. You can add a small wrapper layer to copy files chosen with the FileOpenPicker to your ApplicationData.TemporaryFolder and then use C runtime calls to read it from there.

    If at all possible, I would try to refactor the code to accept streams rather than making an extra copy.

    --Rob

    Tuesday, January 29, 2013 2:47 AM
    Owner
  • Thank you. 

    Code is well structured, it has lower-level IO layer, that uses fopen/fread/fclose for now.

    And it can be easily replaced any other IO API calls.

    I already have implemented connection between .Net and native through p-invoke.

    Copying files, is not possible, because of their size (1Gb in average).

    The only situation it can copy files, is when user picks the file and app copy it into subfolder in docs. 

    Unfortunatelly, cannot open this page. Shows "Content removed":

    http://msdn.microsoft.com/en-us/library/windows/apps/hh464966.aspx

    Best regards, 

    Moskvichev Andrey V.

    Tuesday, January 29, 2013 6:57 AM
  • If your IO layer is already well separated then switching to using StorageFiles as returned from the FileOpenPicker will be the best solution. Copying files is a hack I'd only use if you couldn't convert the code.

    I'm not sure what the hh464966 page is supposed to be. If you can let us know what you were looking for we might be able to find the right link.

    --Rob

    Wednesday, January 30, 2013 12:41 AM
    Owner