I've written a C++ Windows Runtime Component and consume it from a C# Windows 8 app. I'd like to use that same runtime component in a Windows Phone app. Since Windows Phone allows for C++ runtime components, I assumed I could reuse the original runtime component, however it's not targeting Windows Phone right now. Is there some way of modifying my runtime component project to target both Windows Phone and Windows?
I don't want to have to create a separate Windows Phone Runtime Component, duplicate all of the code and maintain two versions.
I'll preface by noting I don't do much coding on the C++ side of Visual Studio, but this should get you close.
You will need two separate projects, but you could set one project up to house all the files and then in the second project Add->Existing Item... to the source/.h in the first project. In C++ (unlike VB/C#) a reference is included to the original location and a copy is NOT made.
I'm presuming #ifdef can be used to work around any differences in the implementation (as is also recommended as an option for C# targeting both Windows 8 and Windows Phone)
Related
Using XCode I created 12 identical frameworks, only their names are different (each deriving from its respective XCode project name).
Following this guideline I embedded one of the frameworks into a Xamarin.ios project as a native reference.
Using [DllImport("Framework", EntryPoint = "Functionname")] I am able to access any of the 12 frameworks in both, Debug and Release mode and on both, Simulator and device. So far, so good.
BUT, when adding all of the 12 frameworks to the Xamarin.ios project strange things start to happen during the run on a device (the Simulator is somehow not affected!): only a couple of the frameworks can be accessed (normally 4), the rest throws a Dllnotfound exception. And even more: depending on the sequence of adding a framework to the Xamarin.ios project it may be accessed or throw the exception(!) For example if I start the adding process with one of the 8 "bad" frameworks from a former build process, this one will no longer be bad and can be beautifully accessed - in return one of the accessible frameworks from a former build process will then throw Dllnotfound.
To clarify, the 12 frameworks all have the same inner life, only different names and different entry point names, the rest is completely identical, hence interchangeable.
My first thought was a limit in number or size of embedded frameworks that was established for Xamarin projects?? In my case the app's total size with 12 frameworks is around 110 Mb in Debug mode.
My next thought was a possible symbol collision between the frameworks: But these are not static libraries using "Internal__" with a huge pool of all symbols together, but a strictly separated set of frameworks with different names (container system). Furthermore, a symbol collision would lead to an error during build, not during run...
Another thought was about my free provisioning profile: maybe with a paid developer account there is no limit for the number of frameworks to be embedded?? That would explain, why it's always working on the Sim...
Some more things I have tried and all potential combinations of them as well (though without success so far):
Using different versions of XCode to build the frameworks (version 8 and 11)
Using different versions of Visual Studio for Mac to build the calling program (2017 and 2019)
Using different versions of deployment on a device (iOS 10.3 and 13.2)
Using the option "smart link" for the native reference in Visual Studio
Using the option "force load" for the native reference in Visual Studio
Using additionally the option to specify linker flags in "additional mtouch arguments" for the native reference in Visual Studio
Using the setting "Link all assemblies" in Visual Studio
Am I missing something in my process, in my setup or in my idea?
Any help would be appreciated after so much time of investigation. Thanks:-)
This should not be so difficult!
In normal C++ one can write static or dynamic libraries that can be used in multiple application projects. I want to do the same thing for UWP apps using C++/winRT.
I have written a simple C++/winRT UWP app that discovers Bluetooth Low Energy Devices. I used the Core UWP project template that set up all that pch.h stuff. What I want to do is to make a library out of the code I wrote that did the Bluetooth work so it can be shared across many UWP apps but I have no idea which project template I should use to do that.
I have come to the conclusion that writing a Windows Runtime Component is not what I want. I am not making a run time component though I need to use runtime components for the Bluetooth.
In the end I will be calling that library from a Java application but that's off in the future.
All my problems would be solved if they had a Java/winRT option (a Java language projection in Microsoft-speak).
Note that the project selection interface in Visual Studio 2019 must be very different than 2017 as none of the demos I have seen online look like what I see.
Right now it's possible to build multiple flavors ( not version ) of Android app or iOS app using "flavor" and "target" features respectively. Already have created iOS and Android apps which need such "flavoring". Now same app is to be developed as Windows Universal App. Is it possible to do it in current SDK of Universal Windows App?
Universal Windows Apps are apps that run on windows 10. At the moment there is only one "flavor" of windows 10 so you can only build against that. As more updates come you will be able to target any range of versions and device families you like.
It's all mentioned in this guide.
EDIT: Different meaning of flavors
If by flavors you mean keeping the same code base with minor changes and publishing multiple flavors of an app then I am not aware of any tool that provides such capability in visual studio.
if that is what you want then you will have to do it manually. Create the store packages for the first flavor of your app, then perform the code base changes (by adding or removing files or an other way you want) and then create the new store packages.
My Visual Studio 2012 solution has C# projects, VB.NET projects, C++/CLI projects and C++ projects. Currently, I have three platforms: x86, x64 and Win32. When I added x64, I noticed it was used by all projects. I'd like to do the same with x86, so that I can remove Win32.
So I went to Configuration Manager, selected a C++ project and in the platform combo box I only had the options: Win32, x64, New and Edit. If I selected New, the only option available is ARM.
So then I thought of just replacing Win32 with x86 in my .vcxproj. Didn't work (it defaulted to x64). Then I looked at the .sln file, but couldn't see how x64 manages to work for every project.
The IDEs differ too much to get a common platform name for 32-bit code. Otherwise reflective of managed code being rather fundamentally different from C++ code. Managed project platform names can only be AnyCPU, x86, x64. C++ project platform names can only be Win32, x64 and ARM. History plays a role, Win32 comes from the early 1990s, back when Windows NT introduced the 32-bit version of the winapi. Distinguished from the 16-bit version. There was no real opportunity to ever change it again without risking breaking existing projects.
The x86 platform name for managed projects isn't exactly standard either, that was a mistake in VS2010 that you appear to have inherited. VS2012 creates new projects with the AnyCPU platform name like old VS versions used to do. Which pretty accurately describes the true platform for managed code, it runs on any thanks to the jitter. The name is otherwise irrelevant, only the Project + Properties, Build tab settings matter to force a specific jitter to be used at runtime. In other words, if you don't force x86 there then your program is still going to run as a 64-bit process, even though the platform name is x86. That was the VS2010 mistake, it caused a lot of misery.
So you're pretty stuck with this. It is not a real problem, the IDE can handle the mix just fine. You already know about the Build + Configuration Manager dialog, it unambiguously shows which platforms are going to be built when you use Build + Build or press F5.
I've just recently started working with Visual Studio this summer, primarily on CUDA and OpenCV related projects. Prior to this, I had been doing my development on Linux for CUDA using Makefiles and the common.mk makefile from NVIDIA.
So my question is as follows: I've not been able to figure out for the life of me what the difference between some of the different project templates are. I know that I've had to use "Empty Project" from the general tab of the Visual C++ options, but that's more trial and error, rather than actually knowing what is going on...
A Win32 project is used if you want to end up with a DLL or a Win32 application usually using the bare WinAPI. A common language runtime (CLR) project is used to create C++/CLI project, i.e. to use C++/CLI to target the .NET platform.
The main difference between projects is what Visual Studio comes up with in terms of pre-created files. A windowed Win32 application for example (what you get when you choose Win32 project, but not a DLL) is created with a file for resources (menus, accelerators, icons etc.) and some default code to create and register a window class and to instantiate this window.
When creating a Win32 project, the linker Subsystem is set to Windows. When creating an empty C or C++ project the subsystem is set to console. Likewise the entry point in the settings for Win32 projects expects a WinMain or DllMain while a console expects an int main. A CLR allows you to mix C++ and .NET which is usually discouraged against.
A Windows subsytem can target executables, dlls, libs or driver/native(sys) files. While a console subsystem targets console binary executables. WinMain is typically used when creating an actual Window application using the CreateWindowEx API, establishing message callbacks and inserting a message handler loop.
A console subsustem with int main can also create a Windowed application only you're better off doing it with WinMain.
A Dll empty project sets the subsystem to Windows and setting to the compiled output to (.dll) as well as the entry point to DllMain/APIENTRY and a static lib will do the same as the Dll except it will set the output to (.lib).
Setting the project to Native subsystem will require the Windows Driver Development Kit to compile drivers.