hello, thanks for reporting. Unfortunately, I do not run windows, so the support for it is not really guaranteed.

If you could fix this and contribute the fix in a PR, that would be wonderful.

Thank you!

+1

hello, thanks for reporting. Unfortunately, I do not run windows, so the support for it is not really guaranteed.

If you could fix this and contribute the fix in a PR, that would be wonderful.

Thank you!

I do not have that high level knowledge to know how to fix this problem :\

@qmatteoq and @sanjeevjadhav15 is this something you might have some insight into? I think there's a min react-native-windows version somewhere that is causing issues here? Sorry I can't be more helpful, but we're also not sure how to address this issue.

Looks like they have a suggestion over on react native for windows: microsoft/react-native-windows#10059 (comment)

@jonthysell, I tried the work-around with the Directory.Build.props and didn't have any success. Could you suggest/drop a pull request in this project with the experimental.props change you suggested (I don't really understand what that means, and it sounds like there isn't a lot of Windows support on this project)? Any help you can lend would be awesome, as this is blocking us from upgrading to react-native/react-native-windows 0.69.1.

Still getting the following output
error NU1201: Project Microsoft.ReactNative is not compatible with uap10.0.16299 (UAP,Version=v10.0.16299). Project Microsoft.ReactNative supports: native (native,Version=v0.0)

Even after creating a Directory.Build.props ref'ing 10.0.19041.0 in the project directory, one level above node_modules (also tried adding it inside the node_modules, but nothing changed).

None of the obvious changes worked, so we went "back to the drawing board".

Turns out the official RNW docs has a very vague sketch of a native module with the Windows Picker: https://microsoft.github.io/react-native-windows/docs/native-modules-async#executing-calls-to-api-on-the-ui-thread

We wanted to show an open file picker and bring the contents back to JS. https://docs.sheetjs.com/docs/demos/desktop/#react-native-windows is a complete demo from scratch, but the highlight is:

  REACT_MODULE(DocumentPicker);
  struct DocumentPicker
  {
    /* The context must be stored when the module is initialized */
    REACT_INIT(Initialize);
    void Initialize(const ReactContext& reactContext) noexcept {
      context = reactContext;
    }

    REACT_METHOD(PickAndRead);
    void PickAndRead(ReactPromise<winrt::hstring> promise) noexcept {
      auto prom = promise;
      /* perform file picker action in the UI thread */
      context.UIDispatcher().Post([prom = std::move(prom)]()->winrt::fire_and_forget {
        auto p = prom; // promise -> prom -> p dance avoids promise destruction

        /* create file picker */
        winrt::Windows::Storage::Pickers::FileOpenPicker picker;
        picker.SuggestedStartLocation(PickerLocationId::DocumentsLibrary);
        picker.FileTypeFilter().Append(L".xlsx");
        picker.FileTypeFilter().Append(L".xls");

        /* show file picker */
        StorageFile file = co_await picker.PickSingleFileAsync();
        if(file == nullptr) { p.Reject("File not Found"); co_return; }

        /* read data and return base64 string */
        auto buf = co_await FileIO::ReadBufferAsync(file);
        p.Resolve(CryptographicBuffer::EncodeToBase64String(buf));
        co_return;
      });
    }

    private:
      ReactContext context{nullptr};
  };

The JS integration is straightforward when added to an app directly (and there is presumably a similar integration for modules):

// at the top of App.js
import { getEnforcing } from 'react-native/Libraries/TurboModule/TurboModuleRegistry';
const DocumentPicker = getEnforcing('DocumentPicker');

// ... whenever the picker should be called
          const b64 = await DocumentPicker.PickAndRead();

@vonovak with some work, the entire library interface can be implemented in this manner. Would you entertain a complete replacement of the existing C# module with a C++ one? The compatibility matrix suggests that a C++ module would have broader compatibility than a C# module.

I was able to workaround this by going into node_modules/react-native-document-picker/windows and opening up ReactNativeDocumentPicker.sln in Visual Studio. On the right pane, I right clicked the project file ReactNativeDocumentPicker and went to Properties. There I changed the Target version to 19041 and the Min Version to 17763. Then in Visual studio, I clicked Build -> Clean Solution and then Build -> Rebuild Solution. The build gets errors about ReactNativeManaged.dll, but for some reason I am able to build my react native windows project with no issues.

I also tested this on document picker version 6.0.4 and it worked and the build was successful in Visual Studio as well.

Looks like there are 2 issues tracking this. I left a comment in the other one with links to how this has been addressed in other modules: #676 (comment)

I was able to workaround this by going into node_modules/react-native-document-picker/windows and opening up ReactNativeDocumentPicker.sln in Visual Studio. On the right pane, I right clicked the project file ReactNativeDocumentPicker and went to Properties. There I changed the Target version to 19041 and the Min Version to 17763. Then in Visual studio, I clicked Build -> Clean Solution and then Build -> Rebuild Solution. The build gets errors about ReactNativeManaged.dll, but for some reason I am able to build my react native windows project with no issues.

I also tested this on document picker version 6.0.4 and it worked and the build was successful in Visual Studio as well.

Just ran into the issue today and this was the workaround that worked instantly for me. Thanks!