I am using the ArcGis functionality in a class library that Is implemented as a prism module. When I build the module, the client32 and/or client64 folders do not get copied into the build output as they do if I create a WPF application and reference the ESRI libraries. With these dependencies missing, the application crashes. What are your recommendations for bringing these folders into the build output for class libraries? I can do some post install step and copy them in if needed.
As long as your project targets NET Framework 4.5.2 or greater (net452) the deployment should be created in your output folder. The Esri.ArcGISRuntime.dll will look for the deployment in the executing app's folder. We're just investigating some interesting behavior with AnyCPU versus x86/x64 platform targets for class libraries.
- What is your current platform target? (AnyCPU / x86 / x64)
- If it's AnyCPU, what happens if you switch to x86 or x64 specifically, save the project, and rebuild?
- If after doing that, what happens if you switch back to AnyCPU, save the project, and rebuild?
The NuGet targets file should take care of the deployment in all the cases above, but ultimately the files you need are in "...packages\Esri.ArcGISRuntime.WPF.100.0.0\lib\net452\arcgisruntime100.0".
Sorry for the delay. I tried switching to x64 from AnyCPU and the behavior was the same. If I add a reference to the ESRI assemblies to the main application, it works fine. But being a prism application, I should not have to. That is a workaround.
Copying the deployment folder to your project's output directory happens as a result of build commands managed by the Runtime NuGet package. If you've not added the package to a project (be it an application or otherwise), then it has no knowledge of that project and therefore has no mechanism to perform the copy. This is a limitation in your particular use case. You will either have to reference the Runtime in your main app or manage copying of the deployment folder explicitly.
Hope this helps.
I had a similar issue with my application although the problem was in the startup project. I call ArcGISRuntimeEnvironment.Initialize() in my startup prior to running the bootstrapper so I do need a reference to Esri.ArcGISRuntime in that project. For this project setting to target x64 resolved the problem.
I design my application with a core Infrastructure library which is not a module and compile all the module output the bin folder of this project (I use MEF for kind of pseudo DI and use directory discovery to load modules). The core library is set to Any CPU and in this project the two sub folders (client32 and client64) did deploy
The native binaries and resources are not deployed with class libraries, because that wouldn't help you anyway. When referencing that class library, your application wouldn't know it to also deploy the native resources. Therefore it's a requirement that you either reference the nuget package from your application, or you xcopy deploy the arcgisruntime100.0 folder yourself.
It doesn't seem like there was ever a resolution to this problem. I am running into the same issue with an application that I'm working on. I am developing a mapping module that has to be run from a C++ context, so I have created a C# class library that references the Esri.ArcGISRuntime libraries that is called from a C++/CLI wrapper so that my WPF mapping windows can be displayed from a C++ application.
The problem that I am running into is the same as the original poster. Whenever I build my class library, an ArcGISRuntime100.4 folder is being created, and inside of that is a resources folder, but there is no Client32 or Client64 folders being generated.
Compile the project with target set to x86 and then again with it as x64. It should create the folders that way. Then you can change back to Any CPU. That has been my expereince