I made a Windows Runtime Component with VS2013, using C++/CX and targeting Universal Apps. Therefore, I now have 5 DLL files:
Windows
ARM
MyLib.winmd
MyLib.dll
x86
MyLib.winmd
MyLib.dll
x64
MyLib.winmd
MyLib.dll
WindowsPhone
ARM
MyLib.winmd
MyLib.dll
x86
MyLib.winmd
MyLib.dll
My customer wants to use this library in a Windows 8.1 project. He told me that he cannot use the lib with a project targeting "AnyCPU", which is normal since each DLL is for a single platform. However, what should I tell him? How should he create his project in order to get a package working on each platform?
AnyCPU is not supported for native code, only for pure managed code.
You'll need to distribute the platform specific modules and your customer will need to target specific architectures and include the appropriate version of the component for the target architecture.
One way is to put the component in folders named for the configuration and choose the version to reference by the $configuration property.
An easy way to set this up is to distribute the component as an extension SDK which will set up the appropriate directory structure and include the matching version for the configuration. See Distributing a managed Windows Runtime component and How to: Create a Software Development Kit on MSDN (the managed doc has a good overview even for native components).
A nuget package can also achieve the same thing.
Related
When compiling my Rust app in Windows 10, it is linked against ucrtbase.dll; however, this dll does not exist on some editions of Windows Server 2008 R2 Datacenter, making my app impossible to execute.
I tried setting -Ctarget-feature=+crt-static as found here, but it did not do anything; ldd app.exe still shows this dll.
Is there a way of removing the dependency on this dll?
If your Rust app does not depend on C libraries that specifically require the MSVC toolchain, you can build it for the x86_64-pc-windows-gnu (or i686-pc-windows-gnu, to build for 32-bit CPUs) target instead. This target links to DLLs that are available in all Windows versions.
For more information about the different Windows ABIs, you can check out this documentation page.
I have the following question:
I'm using CakeBuild to build my Xamarin.Forms solution on a Windows computer (Windows 10).
Everything builds fine when I'm using the following command:
MSBuild("MyXamarinApp.sln", configurator =>
configurator.SetConfiguration("Debug")
.SetMSBuildPlatform(MSBuildPlatform.x86));
But if I remove "SetMSBuildPlatform(MSBuildPlatform.x86)" it uses internally "MSBuildPlatform.x64" and then I get the following error:
(_GetReferenceAssemblyPaths target) ->
C:\Program Files (x86)\MSBuild\Xamarin\Android\Xamarin.Android.Common.targets(566,2): error MSB3644: The reference assemblies for framework "MonoAndroid,Version=v1.0" were not found. To resolve this, install the SDK or Targeting Pack for this framework version or retarget your application to a version of the framework for which you have the SDK or Targeting Pack installed. Note that assemblies will be resolved from the Global Assembly Cache (GAC) and will be used in place of reference assemblies. Therefore your assembly may not be correctly targeted for the framework you intend.
Can someone explain this behaviour? Can I only use the x86 version of MSBuild to build Xamarin projects?
You need to set that platform in you Android application target. (AndroidProject -> Options).
x86 that desktop architecture. You can use it to build and test on simulator, but for a real device you will need to select at least one mobile architecture (any architecture that's not x86 or x86_64)
We are developing a DLL, which calls generic WinUsb functions from WinDDK. This DLL needs to work in 32-bit and 64-bit versions of Windows, including xp, vista, win7, and possibly win8.
My question is, how can we manage the Visual Studio 2010 solution by targeting all these platforms? WinDDK libraries are different for each OS, so if I reference a library from the code:
#### #pragma comment (lib , "C:\\WinDDK\\7600.16385.1\\lib\\wlh\\i386\\winmm.lib" )
Or by referencing the library from the project options->includes section, this project only becomes correct for a particular target architecture. (In this example, Vista 32-bits, since I am including 'wlh').
Are we supposed to create a different project for each different OS target?
The WDK/DDK version does not constrain the OS version for which you build. You can pass the target OS as a build environment/compile parameter.
I think you should build DLL through DDK and use that in your VS project.
You can write pre-build event for your VS project to run a batch file which will build the DLL and put it in some well-known place for the project.
Also, you may have to create different project configurations for each platform you want to build for (at least different for 32-bit and 64-bit) and run appropriate build command for DLL.
I want to create a Cocoa framework that can be included in a 32-bit or 64-bit application. Is there a way that I can create a single universal build of my framework that will work in both? Or do I have to compile two different versions of my framework?
Figured it out. With the default configuration, a new framework will build universal when you build it as Release, but built as Debug, it is by default your own architecture only (to speed it up).
So either build as Release (recommended) or edit the target settings and change the key (Build Active Architecture Only) for the Debug configuration.
I have a Windows .net solution that is deployed with a Visual Studio Deployment project.
My exe is a win32 app that runs fine on either a x86 or x64 windows.
However I included a merge module (*.msm) from a third party vendor which is available in a x86 and x64 version.
Now I could copy my whole deploy project and just change the msm, but I'm a lazy guy and the best thing would be to include both msm's in my installer and only install the module which fits the processor of the client machine.
Is there a way to do this with Visual Deployment projects?
Merge Modules seem to lack a Condition property like included exe / dll files have.