Universal Windows Platform/UAP: what is AOT? - windows

I recently created a blank UWP application in Visual Studio 2015, and then tried to add a nuget package to that application. The package installation failed and resulted in the following messasges in the output window...
System.Reflection.Emit.ILGeneration 4.0.1 provides a compile-time reference assembly for System.Reflection.Emit.ILGeneration on UAP,Version=v10.0, but there is no run-time assembly compatible with win10-arm-aot.
One or more packages are incompatible with UAP,Version=v10.0 (win10-arm-aot).
System.Reflection.Emit.ILGeneration 4.0.1 provides a compile-time reference assembly for System.Reflection.Emit.ILGeneration on UAP,Version=v10.0, but there is no run-time assembly compatible with win10-x64-aot.
One or more packages are incompatible with UAP,Version=v10.0 (win10-x64-aot).
System.Reflection.Emit.ILGeneration 4.0.1 provides a compile-time reference assembly for System.Reflection.Emit.ILGeneration on UAP,Version=v10.0, but there is no run-time assembly compatible with win10-x86-aot.
One or more packages are incompatible with UAP,Version=v10.0 (win10-x86-aot).
Looking around, I have found references to the "runtimes" within the "project.json"; (mine looks like this)...
{
"dependencies": {
"Microsoft.NETCore.UniversalWindowsPlatform": "5.1.0"
},
"frameworks": {
"uap10.0": {}
},
"runtimes": {
"win10-arm": {},
"win10-arm-aot": {},
"win10-x86": {},
"win10-x86-aot": {},
"win10-x64": {},
"win10-x64-aot": {}
}
}
My question is this: what is the difference between each "runtime" and the equivalent runtime with "-aot" appended?
I have seen some posts that indicate I can delete these runtimes if I want to use a nuget package that does not support them, but I would prefer to only delete them knowing what they are.
Note: I do not know if this makes any difference, but the UWP application that I am building is expected to only ever be side-loaded (it is a line of business application). It may however eventually need to be distributed via the Windows Business Store in order to ease updates etc.
Thanks.

Runtime is a general term that refers to any library, framework, or platform that your code runs on. The win10-arm and win10-arm-aot runtimes are different platforms. Here is a Wikipedia: Runtime system.
Besides, as per Wikipedia Ahead-of-time (AOT):
Ahead-of-time (AOT) compilation is the act of compiling a high-level
programming language such as C or C++, or an intermediate language
such as Java bytecode or .NET Common Intermediate Language (CIL) code,
into a native (system-dependent) machine code with the intention of
executing the resulting binary file natively.
Some programming languages with a managed code runtime that can be compiled to an intermediate language, take advantage of just-in-time
(JIT)
So I agree with Hans Passant, the AOT compiler is incompatible with System.Reflection.Emit.ILGeneration package. So you can delete these aot runtimes if you want to use this package.

I found the solution to my case. I had several projects in my solution and all of them were using
Microsoft.NETCore.UniversalWindowsPlatform V 5.2.3
except for one project. It was using
Microsoft.NETCore.UniversalWindowsPlatform V 5.0.0
When I update the 5.0.0 to 5.2.3 all the errors went away.
NOTE: You do not need to remove aot tags from the JSON files.

Related

How to properly build third-party library to be used in Debug and Release configurations in my project?

When I need to build some third party library to be used in several of my projects under different version of MSVC, I usually build it for every MSVC version and for both Debug and Release configurations. That's what boost does, and that's what we have been done for our whole life in my team.
However, I still don't get, why couldn't I just build this library with like... whatever. All I need is function prototype and object code, right? Since I'm linking CRT statically, I have no external dependencies. But when I'm trying to link library built in Release under MSVC8 with my project in Debug under MSVC10 I have this annoying "already defined" linker errors which we all hate so much.
But why? Can I just "encapsulate" all this functions inside lib and do not export them so that my project will take only what it needs from the lib? Why can I have precompiled version of libpng and zlib which I can link in every project? Yes, they are not build using MSVC, I guess, but the still uses the same functions of CRT. So can anyone please explain in depth or share a link to some enlightened explanation of this issue?
Since I'm linking CRT statically, I have no external dependencies
Well, that's not true, you do have a dependency. On the static version of the CRT. Debug or Release, depending on your build settings. And it is an external dependency, the linker glues the CRT later, when the library gets linked. The code that uses the library also has a dependency on the CRT. And if the compile settings don't match then the linker barfs.
You isolate that dependency by building a DLL instead of a static link library. You must further ensure that the exported functions don't cause a CRT dependency. You can't return a C++ object from the standard C++ library and can't return a pointer to an object that needs to be released by the client code. Even passing structures is tricky since their packing is an implementation detail, but you usually get away with it. A good practical example is COM automation, it forces you into using a subset of types that are universal. Windows is rife with them and all these servers work with any version of the compiler or CRT. Even any language. This however comes at a cost, writing such a library isn't as simple or convenient as just throwing a bunch of code in a static lib.

pthread win32 version? (Mongoose)

Please tell me what difference between pthread versions: VC2, VCE2 and VSE2? How to choose which of them I must use with Visual C++ Express 2010 for Mongoose webserver library?
Thank you!!!
VCE - MSVC dll with C++ exception handling
VSE - MSVC dll with structured exception handling
VC - MSVC dll with C cleanup code
Which one you'd want to use with VC++ Express 2010 depends on how you want pthread clean up to be handled. If you're linking this to the Mongoose webserver (which I'm not familiar with), I think you'll want to use the exception handling model as that code is compiled with.
The pthreads Win32 library goes into a fair bit of detail:
Library naming
Because the library is being built
using various exception handling
schemes and compilers - and because
the library may not work reliably if
these are mixed in an application,
each different version of the library
has it's own name.
Note 1: the incompatibility is really
between EH implementations of the
different compilers. It should be
possible to use the standard C version
from either compiler with C++
applications built with a different
compiler. If you use an EH version of
the library, then you must use the
same compiler for the application.
This is another complication and
dependency that can be avoided by
using only the standard C library
version.
Note 2: if you use a standard C
pthread*.dll with a C++ application,
then any functions that you define
that are intended to be called via
pthread_cleanup_push() must be
__cdecl.
Note 3: the intention was to also name
either the VC or GC version (it should
be arbitrary) as pthread.dll,
including pthread.lib and libpthread.a
as appropriate. This is no longer
likely to happen.
Note 4: the compatibility number was
added so that applications can
differentiate between binary
incompatible versions of the libs and
dlls.
In general: pthread[VG]{SE,CE,C}c.dll
pthread[VG]{SE,CE,C}c.lib
where: [VG] indicates the compiler
V - MS VC, or G - GNU C
{SE,CE,C} indicates the exception
handling scheme SE - Structured EH,
or CE - C++ EH, or C - no exceptions
- uses setjmp/longjmp
c - DLL compatibility number
indicating ABI and API
compatibility with applications built against
any snapshot with the same compatibility number.
See 'Version numbering' below.
The name may also be suffixed by a 'd'
to indicate a debugging version of the
library. E.g. pthreadVC2d.lib.
Debugging versions contain additional
information for debugging (symbols
etc) and are often not optimised in
any way (compiled with optimisation
turned off).
For example:
pthreadVSE.dll (MSVC/SEH)
pthreadGCE.dll (GNUC/C++ EH)
pthreadGC.dll (GNUC/not dependent on
exceptions) pthreadVC1.dll (MSVC/not
dependent on exceptions - not binary
compatible with pthreadVC.dll)
pthreadVC2.dll (MSVC/not dependent on
exceptions - not binary compatible
with pthreadVC1.dll or pthreadVC.dll)
The GNU library archive file names
have correspondingly changed to:
libpthreadGCEc.a libpthreadGCc.a
If you want to see what the differences are for each of these clean up models, search for "__CLEANUP" in the pthreads Win32 source (there are only a few places where the different clean up models come into play).

Using /clr and noclr libraries in one project

I am encountering some issues with one project. I need to use two libraries but one needs to be compiled with the /clr switch as the other cannot be compiled with this switch.
Would there be a way to use at the same time those two libraries in one project? Currently it's compiled with /clr and I got linking errors with the noclr library.
If there is no solution I can still launch the noclr library in batchmode but I'd like to avoid it...
My project is in Managed C++, the library tetgen - which needs /clr - is in native C++ and cannot be compiled without the /clr switch, as I get this error
error C3381: 'tetgenio' : assembly access specifiers are only available in code compiled with a /clr option
The other library triangle is in C. I am on Visual Studio 2008 and the project is compiled in 32 bits.
We could use more details, but using managed C++ you can certainly use a mix of managed and unmanaged code. (Microsoft calls their managed c++ code C++/CLI.)
EDIT:
Ok, your compiler error helped. Apparently you have specified a native class, but using public private, or some other access specifier on the name of the native class. From the MSDN docs:
The following sample generates C3381:
// C3381.cpp
**public** class A { // C3381. Remove public or make the class
managed. };
int main() { }
so get rid of the public keyword, and then try compiling again.
You can have multiple projects in a single solution. Right click on the solution in the eolution explorer and add -> existing/new project. Each library project can be added that way and have their own clr settings.

Runtime Issues While Mixing Libraries from Different Versions of Visual Studio

I have encountered an unexpected Access Error while running a project I've built using two different versions of Visual Studio. My general configuration is as follows:
LibA is a static lib, static runtime linkage, msvc 8.0
LibB is a static lib, static runtime linkage, msvc 9.0
My target project for integration is a msvc 9.0 COM dll, which statically links the above libraries
This project builds, but crashes up at runtime with an access violation in some STL code. The stack seems to indicate that I've passed through headers both versions (8 and 9) during a call into a stream insertion operator. I realize that this is a problem.
Somehow, this call:
ost << std::dec << port_; //(originating from an object in LibA)
...descends through the following stack trace:
std::basic_ostream::operator<<(...) (ostream:283, msvc 8.0 version <-- expected, since LibA was built with this version)
std::num_put::put(...) (xlocnum:888, msvc 8.0 version <-- expected, since LibA was built with this version)
std::num_put::do_put(...) (xlocnum:1158, msvc 9.0 version!! !##$!%! <-- not expected, since LibA was built with msvc 8.0)
std::ios_base::flags() (xiosbase:374, msvc 9.0 version <-- follows from above)
The access violation happens in std::ios_base::flags(). I suspect it is due to the mix of implementations in the call stack (although I am not sure).
My questions are.
1.) Is the likely cause of this access violation the mixing of msvc header implementations?
2.) Is there a way to prevent these implementations from mixing?
3.) Is there a better way to configure these three projects for integration (assuming moving LibA from msvc 8.0 is undesirable)?
I am aware of the ideas raised in this question and this one. Here I am most interested in this specific problem, and if there is some way to avoid it.
Any insights would be appreciated.
You can't use different STL implementation in the same project. This means even different versions from the same compiler. If your LibA has a function that accepts std::vector as an argument you are only allowed to pass vector object from STL that LibA was built with. This is why many C++ libraries expose only C API.
Either you change your API or you rebuild all your projects using the same compiler.
You are doing something that you shouldn't. You are in the world of undefined behavior. There is no point in trying to debug this particular crash. Even if you managed to make this line work you would get a new crash somewhere else.
There is no guarantee of library binary compatibility between major versions of MSVC. STL code is mostly template code that gets expanded into your code. So you're static libraries probably have incompatible chunks of STL code inside of them.
In general, this shouldn't be a problem, unless that STL code is part of the interface to the library. For example, if you pass iterators or a reference to a vector from one library to another, you're in trouble.
The best solution is to build everything with the same version of the compiler. If you can't do that (e.g., if the one of the libraries is from a third-party), you're probably stuck.

Dependency on VCOMP90.DLL in VS2008 Pro OpenMP project

I have a DLL project in VS 2008 Pro which uses OpenMP. I use /MT as 'code generation' option, because I want all my dependencies statically linked into my DLL, since I do not want to distribute many libraries to my clients - everything shall be included in this one DLL file. The problem is that my resulting DLL still depends on VCOMP90.DLL.
How can I get rid of this dependency?
Some information:
/openmp is set in compiler options
I statically link against vcomp.lib
include is set
using multithreaded library (/MT)
Thanks a lot for your help!
I don't think you'll be able to get rid of the DLL dependency - vcomp.lib is an import library for the VCOMP90.DLL - it's not a static library:
http://msdn.microsoft.com/en-us/library/0h7x01y0.aspx
It doesn't look like a static lib is provided.

Resources