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:-)
Related
If I'm in my WSL2 Ubuntu filesystem I can simply navigate to a javascript/nodejs folder and type code . to open that project folder and thanks to VS Code's Remote extensions, I'm essentially remoting into the Linux environment and ready to code.
Now Visual Studio 2022 has been released, I was wondering if it too supports the same level of cross-platform IDE capability as VS Code?
How, for instance, when in my WSL2 Ubuntu project in Windows Terminal, can I open my javascript/nodejs project in the Linux filesystem using VS2022, or is this not supported because VS Code is the only cross-platform IDE that can do this?
So its not really possible to do how your thinking. The problem here is that you your not understanding the difference between a "Code Editor", and an "Integrated Development Environment (IDE)", which is totally understandable, as the line that separates the two has become blurred in recent years, and also a topic of debate. There was a far more explicit distinction between the 2 10-15 years ago, however, Microsoft has done a good job at separating the two, where JetBrains will release a piece of software that can be used as an IDE, but is more often than not, used as an editor, but will still call it an IDE, even though its not an IDE in a pure sense.
How is all this related to your question?
When you open your Node.js project in VSCode via the code . command, you are opening it in an editor that implements Intelli-code, as well as a wealth of other tools, but essentially, the editor, and all the tools extract the names & file extensions of your documents, parse them (usually turning much of the info into an AST, where many extensions will make use of that info to offer the various tooling capabilities/features. The point is at the end of the day, the editor just parses all of your code, gives you info, and you make any changes as needed to your code. And again, this is what your doing with code .
With Visual Studio 2022, you can't open a project with it, unless its a project type the IDE supports, and enables the IDE, to embed its-self into your project. This includes things like built in environment, built in cache, built in build system, the files needed to bootstrap its-self. With an IDE, the IDE is part of the project.
So then why does Visual Stdio 2022 work with Node?
It works with node, to create Node.js applications within a windows environment, and it offers the ability to access different Windows SDK features via Node. These are things you could never do using server-side Linux builds with Node. When you build a Cpp application for windows, you package the entire thing in a .sin file, I haven't built a windows app in node, but I know that Node also uses the .sin file build system, which requires Visual Studio & Windows SDK to do, and parts of Visual Studio/Windows to be embedded into the project, for the project to be able to work in a Windows OS, and take advantage of MS Windows features.
Long story short, V.S. Code is the right tool for what your doing, why would Microsoft invest in two identical tools any way? If you ever want to build something for Windows, or for MS mobile device using Node, you will probably want to change your environment, to VS2022.
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.
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)
I'm working on WinRt version of my class library dll. Finally, after the huge "code cleanup" my project is on building step and I have two ways. To build the solution with Release|AnyCPU as usually or build it with Release|ARM (Which unclear for me). Which dependencies my dll will get or avoid in process of building, what will be different, will there a specific IL optimizations on a second way?
If you're only using managed code, there's no reason not to use Release|AnyCPU. This way the same package will be used for all three platforms (ARM, x86 and x64).
On the other hand, if your project references natively compiled library, you'll need to set a specific platform, like Release|ARM, that your native library is compiled for. If the native library is installed as an extension (e.g. SQLite for Windows Runtime), you'll be able to compile your app for all 3 target platforms, each one referencing the appropriate native library, though they will need to be individual packages instead of a single universal one.
You'll still be able to submit your app to the store as a single app even if it has 3 separate packages, one for each platform.
We're planning moving from Visual Studio 2005 to Visual Studio 2012 (Visual-C++-11).
(We would very much like to skip 2010 if we can help it, since the newer version is already there and offers a better C++ experience.)
But we've hit a little roadblock:
Our build servers still run Windows 2003r2 (all inside dedicated virtual machines), and due to messy tool support/issues, we're in no position to upgrade the build servers to a newer OS.
Developers mostly have switched to Windows7 by now, so moving the remaining Windows XP developer boxes shouldn't pose a problem.
Since VS2012 only runs on Win7 we are wondering whether we can leverage it's tools (C++ compiler, C#) and still do a full equivalent build on the W2k3 build server - after all, we don't really need a VS GUI there, just build C++ and C# projects from VS2012.
What are our options?
Will the SDK (7.1? 8?) compilers + msbuild command line get me anywhere?
In Project Property Pages, there an option "Platform Toolset" that allow you to choose compatibility of your project. So, you can work in VS2012, but built it with "VS2008 compiler"
Here is what we do:
Use CMake
CMake allows you to create build systems for your operating system. Thus we are able to use the same code within VS2005, VS2010 and Eclipse, XCode etc.
You could do something similar: Install VS2005 on your old machines and let CMake create the projects for you from the sources. On your newer machines you can use CMake to generate VS2012 Solutions (I don't know if they have 2012 support yet, because we don't use 2012 yet too).
A big pro here is: If you plan to migrate to any other IDE or even Linux you just can re-run CMake and get your source code within these environment easily compilable.
A big con: You have to start reading about CMake and create CMakeLists.txt for all your projects (might be a lot of work depending on the amount of projects, amount of source code files within each project, specific compiler options, linker options etc.)
Our build servers still run Windows 2003r2 (all inside dedicated
virtual machines), and due to messy tool support/issues, we're in no
position to upgrade the build servers to a newer OS.
Well. Not much came out of this question. We recently re-evaluated this issue, and I see two options (I haven't tried any yet):
Just do a full VS installation on a supported OS (Win7), zip up the whole VS+WinSDK directories (as well as the neccesary runtme DLLs that live somewhere under %WINDR%), and try if you can get that thing working on an XP based OS. Might work. Not a great idea if you ask me.
Split up the build process to distribute the build across several OS, so that we can work with tools that are only supported on one of them. -- This actually sounds more complicated than it'll be. We already run our build spread over several Jenkins jobs, so I should be able to get that to work. (And all build nodes are already VMs anyway, so adding more VMs isn't that much of an issue.)