locked
Creating a File in desired location working well in WinRT component but not in Windows Store App DLL

    Question

  • I wrote a code in WinRT component to Create a file and Read a File (DocumentsLibrary) and added as a reference to C# proj it worked well,

    Later i created Windows Store App DLL (same code) which will be loaded in Native C++ by

    hInstance = LoadPackagedLibrary(L"Store.dll",0);

    I am able to create a file but unable to write into the file (file is empty). when it try execute

    create_task(FileIO::WriteTextAsync(file, Data)).then([this, file, Data](task<void> task)

    its not responding. same for reading a file too

    IAsyncOperation<String^> ^getString = FileIO::ReadTextAsync(storageFile->GetResults());

    Unable to create a "StorageFile/Folder".but same code was running successfully in WinRT Component.

    I am trying to port win32 code for ARM(surface) target. where i need to create a file in middle of a win32 function so i am calling winRt functions with "LoadPackageLibraray". I try to use 'FindFirstFileEx' its not working.

    Code to create a file

    void ArmStorage::MyCreateFile(String^ FileName,String^ Data)
    {
    	create_task(KnownFolders::DocumentsLibrary->CreateFileAsync(FileName, CreationCollisionOption::ReplaceExisting)).then([this,Data](StorageFile^ file)
    	{
    		create_task(FileIO::WriteTextAsync(file, Data)).then([this, file, Data](task<void> task)
    		{
    			try
    			{
    				task.get();
    			}
    			catch(COMException^ ex)
    			{
    			}
    		});
    	});
    }
    code to read a File

    void ArmStorage::MyReadFile(String^ FileName) { fileData = "GET DATA"; storageFile = nullptr; bProcessCompleted = false; try { IAsyncOperation<StorageFile^> ^storageFile = KnownFolders::DocumentsLibrary->GetFileAsync(FileName); storageFile->Completed = ref new AsyncOperationCompletedHandler<StorageFile^>([=](IAsyncOperation<StorageFile^>^ ope,AsyncStatus status) { IAsyncOperation<String^> ^getString = FileIO::ReadTextAsync(storageFile->GetResults()); getString->Completed = ref new AsyncOperationCompletedHandler<String^>(this, &ArmStorage::OnDone); }); } catch(Platform::Exception^ ex) { } }

    void ArmStorage::OnDone(IAsyncOperation<String^> ^AsOp, AsyncStatus s)
    {
    fileData = AsOp->GetResults();
    bProcessCompleted = true;
    }







    • Edited by J.S.Murthy Monday, April 15, 2013 9:39 AM
    Saturday, April 13, 2013 1:00 PM

Answers

  • I think there is no easy way to do this, you should create WinRT dll to access the document folder.

    By the way, you can use native C++ in WinRT dll. WinRT dll only require the public types as the WinRT type. You can use native class in WinRT and declare them as private.

    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.

    Wednesday, April 17, 2013 2:06 AM
  • Hi Murthy,

    The basic problem here is that your applications (and thus your library) don't have permission to access to the documents library directly.

    Applications do not have direct access to the file system outside of their install and application data directories. Because of this they cannot use Win32 or C-runtime API to access file elsewhere: to access files elsewhere (such as in the documents library) they must go through the StorageItem broker objects. There is no way to access that library without using the Windows Runtime.

    There are a couple of ways you can address this in your library, but the easy ones rely on some changes you may not be able to make:

    1. If you can redesign the API you can have your library handle streams rather than files. Then the location can be opened outside of the library and the stream passed in. Separating the file access from the data processing like this is usually the most general solution.
    2. As you noted (but don't want to do), you can use C++/Cx in your library. With appropriate separation of file access from processing you could do this with a wrapper or second library.
    3. Use COM to call into the Windows Runtime ABI directly without using C++/Cx. See http://channel9.msdn.com/Events/BUILD/BUILD2011/TOOL-690C for more information about how to do this.

    --Rob

     

     

    Wednesday, April 17, 2013 2:53 AM
    Owner

All replies

  • Hi,

    The standard DLLs doesn’t consume or produce public Windows Runtime types. So that we cannot use Windows Store API without add other settings. This DLL is more suit for native C++ codes or Win32 API used in Windows Store.

    Please take a look of this document
    http://msdn.microsoft.com/en-us/library/windows/apps/hh699881.aspx

    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.

    • Proposed as answer by Jesse Jiang Tuesday, April 16, 2013 4:26 AM
    Monday, April 15, 2013 3:05 AM
  • Hi,

    Ok, Is there any other way to create or read all files in middle of a win32 dll function as I told in above scenario.

    Monday, April 15, 2013 6:55 AM
  • Dont know whether this will help, but have you tried using standard C/C++ fopen/fread/fwrite/fclose API's rather than all that 'async stuff'? 
    Monday, April 15, 2013 12:35 PM
  • No it didn't work using standard C/C++ fopen/fread/fwrite/fclose API's.
    Monday, April 15, 2013 1:38 PM
  • Why you need such DLL, you can create a WinRT DLL to use file access API.
    It's possible to create a DLL used in Windows Store and Win32. But this DLL must passed WACK test. Please take a look of http://social.msdn.microsoft.com/Forums/en-US/winappswithnativecode/thread/3df4f1cb-9e9f-4843-87f5-d9bdee031846/

    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.

    Tuesday, April 16, 2013 4:26 AM
  • Hi Jesse Jiang,

    As I mentioned I am porting Win32 code to Windows Store App, My library need to access local documentary files at library level not at application level. The library is Standard DLLs(C/C++) so I create a Store DLL(Windows Store App DLL ) to access documentary files.

    So is there any other way to access local documentary files through standard DLL for ARM target?

    Thanks & Regards,

    Murthy

    Tuesday, April 16, 2013 5:27 AM
  • I think there is no easy way to do this, you should create WinRT dll to access the document folder.

    By the way, you can use native C++ in WinRT dll. WinRT dll only require the public types as the WinRT type. You can use native class in WinRT and declare them as private.

    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.

    Wednesday, April 17, 2013 2:06 AM
  • Hi Murthy,

    The basic problem here is that your applications (and thus your library) don't have permission to access to the documents library directly.

    Applications do not have direct access to the file system outside of their install and application data directories. Because of this they cannot use Win32 or C-runtime API to access file elsewhere: to access files elsewhere (such as in the documents library) they must go through the StorageItem broker objects. There is no way to access that library without using the Windows Runtime.

    There are a couple of ways you can address this in your library, but the easy ones rely on some changes you may not be able to make:

    1. If you can redesign the API you can have your library handle streams rather than files. Then the location can be opened outside of the library and the stream passed in. Separating the file access from the data processing like this is usually the most general solution.
    2. As you noted (but don't want to do), you can use C++/Cx in your library. With appropriate separation of file access from processing you could do this with a wrapper or second library.
    3. Use COM to call into the Windows Runtime ABI directly without using C++/Cx. See http://channel9.msdn.com/Events/BUILD/BUILD2011/TOOL-690C for more information about how to do this.

    --Rob

     

     

    Wednesday, April 17, 2013 2:53 AM
    Owner