I've developed a simple and small Universal Windows App that uses EF7 and SQLite. It compiles and runs smoothly when the option "Compile with .NET Native tool chain" is unchecked.
If I check the option "Compile with .NET Native tool chain", I get the following compilation error:
Error Type 'System.MarshalByRefObject' was not included in compilation, but was referenced in type 'Microsoft.Data.Entity.Design.OperationExecutor'. There may have been a missing assembly.
After this there's a lot of other errors, but I believe that solving this one will also take care of the rest.
Does anyone know how to solve this?
I presume what has happened is that you're using a library that isn't targeting the .NET surface area available to UWP. The surface area for UWP is the set of APIs called .NET Core, you can see the source here: http://www.github.com/dotnet/corefx. Most likely you'll need a newer version of EF... although I know they've had some other issues with our ahead of time compilation strategy (see: https://github.com/aspnet/EntityFramework/issues/3603). We're continuing to work with them to get it sorted out and are hopeful that EF will be in a great place by Update 2 sometime in March.
The reason you only see this with .NET Native is because the compiler is walking your entire application at compile time in order to generate native code for everything that it thinks you're going to call. It happens to notice that this type is unavailable and correctly errors out. I presume you don't actually call this code path in your application because it would produce a similar error on CoreCLR... it would just happen at runtime and not compile time.
If you don't actually need this type (and everything else you need also doesn't need this type etc etc), it's possible that removing this directive from your application will allow the tree shaker to eliminate this type from your application before things go awry:
<Assembly Name="*Application*" Dynamic="Required All" />
This directive causes all of the types in your application and the non framework libraries you reference to be rooted and thus unable to be shaken away. Having this directive by default makes our analysis easier and keeps most folks from having to know too anything about our analysis engine. It's possible that removing this can help you avoid the issue.
Let me know if that works out or if you have any other questions. We always love to get feedback and provide some support at dotnetnative#microsoft.com.
Related
I'm building an REST API on ASP.NET CORE 1.0. In production it'd be IMHO very useful NOT to use JIT because the docker containers with the app are scaling up and down, redeploying during CI over and over, so the just-in-time compilation for every deployed container causes terrible lags, LB health-check deaths and other pains.
As I read, the native compilation with dotnet CLI is discontinued.
I tried building with CoreRT but without luck (details on demand due to complexity).
Since this question is quite abstract I'm not providing sample codes or detailed info, so for the start there are few questions instead:
Is my presumption correct - will ahead-of-time compilation solve the problem with slow first execution of each path -or - isn't there any other solution anyway?
If it's true, is currently possible to build "native" app (ubuntu x64 target) from .NET Core?
If it's, what's the best practice - how can I do it? Does anyone has experience with that?
(The target platform would be ubuntu-14.04-x64 docker image as well as the compilation platform. For develop purposes would be also nice to compile it on OSX.)
Thank you in advance.
Having full native ahead of time compilation isn't possible at this time. It's one of the goals of the CoreRT project linked above but isn't in any state I'd call production ready. The demo at Connect last year should be taken with a pretty big grain of salt. For example they still don't have a reflection subsystem. However, we have a couple of solutions that can greatly reduce the amount of code needing to be generated at JIT time. For .NET Core the tooling is called CrossGen and it's pretty baked these days.
While I have your attention I'll also mention that we're working on an evolution of the NGEN/CrossGen format that alleviates a big chunk of the typical pain involved with typical ni files. That goes under then name ReadyToRun
Hope that helps. Let me know if you have other questions.
Disclosure: I work on the .NET Native runtime and compiler team for UWP (a sister project to CoreRT and LLILC etc)
There is a guide for using CrossGen at https://github.com/dotnet/coreclr/blob/master/Documentation/building/crossgen.md. It's a little out of date - I'll see if I can get it updated sometime. The most important part of using CrossGen is to specify the -Platform_Assemblies_Paths switch on the command line, to tell CrossGen the location of all the dependencies that it needs (e.g., System.Private.CoreLib.dll).
Hope that helps. Please let me know if you run into any further issues.
In my server app, I can get File version info this way:
FileVersionInfo currentVersion = FileVersionInfo.GetVersionInfo(filePath);
...but that trick doesn't seem to work in the Compact Framework (I get, "The type or namespace name 'FileVersionInfo' could not be found (are you missing a using directive or an assembly reference?)"
It seems that the "using" I need in my server/Web API (.NET 4.5.1) app is System.Diagnostics, but adding that to my CF app leaves the using statement greyed out (and doesn't afford the resolution of the err msg shown above).
Do I need to add a specific assembly reference, coupled with a particular "using" to get this to work?
Or do I need to use custom CF code for this, such as that found here?
UPDATE
At the article linked to above, it says, "Getting file version info in the Compact Framework is pretty simple – provided the file you want info on is a managed assembly."
So, okay: what is the simple way? I'll try that first, before I go leaping through fiery hoops. And I know this question will seem naive to many, but: Is a custom .exe we have created (an "in-house" app) "native" or "managed"? I tried googling the difference between the two, but didn't find a definition...
It depends what you mean by "version". As with everything, it's not as simple as it may seem. managed assemblies have a managed version, which is what is set in your AssemblyVersion attribute, something like this:
[assembly: AssemblyVersion("3.0.2")]
This is the version that the managed loader uses and the version that ends up in the type names of the types in the assembly. It's really the "important" version number. It's the version you get if you look at an Assembly's Version Property.
However, it's not the version number that you see when you look at "File -> Properties" in something like Windows Explorer.
Explorer looks at the file for native VERSION_INFO headers, which are completely disconnected from the managed version. For a desktop app, it's set using the AssemblyFileVersion attribute. The Compact Framework, however, doesn't have support for setting that version information. You can work around that if you want, but the CF also has no inherent way to read it back. That's why the blog entry you refer to is talking about - getting the native version info.
So you have to figure out which version you're interested in, then follow the path for setting and getting it. Generally speaking, if it's a managed assembly I try real hard to avoid ever dealing with the native AssemblyFileVersion because it's really not useful for much of anything. Instead I just work with the AssemblyVersion. This is true for CF, desktop or Mono.
I would first like to say my goal is to convert MSIL into native X86 code. I am fine with my assembly's still needing the .net framework installed. NGEN is not what I want as you still need the original assembly's.
I came across ilasm, and what I am wondering is this what I want, will this make pure assembly code?
I have looked at other projects like mono (which does not support some of the key features my app uses) and .net linkers but they simple just make a single EXE with the .net framework which is not what I am looking for.
So far any research has come up with...you can't do it. I am really no sure as to why as the JIT does it when it loads the MSIL assembly. I have my own reasons for wanting this, so I guess my question(s) come down to this.
Is the link I posted helpful in anyway?
Is there anything out there that can turn MSIL into x86 assembly?
There are various third-party code-protection packages available that hide the IL by encrypting it and packing it with a special bootloader that only unpacks it during runtime. This might be an option if you're concerned about disassembly of your code, though most of these third-party packages are also already cracked (somewhat unavoidable, unfortunately.) Simple obfuscation may ultimately be just as effective, assuming this is your underlying goal.
One the major challenges associated with 'pre-jitting' the IL is that you end up including fixed address references in the native code. These in turn will need to be 're-based' when the native code is loaded for execution under the CLR. This means you need more than just the logic that gets compiled; you also need all of the reference context information necessary to rebase the fixed references when the code is loaded. It's a lot more than just caching code.
As with most things, the first question should be why instead of how. I assume you have a specific goal in mind, if you want to generate native code yourself (also, why x86? Why not x64 too?). This is the job of the JIT compiler - to compile an optimized instruction set on a particular platform only when needed, and execute it later.
The best source I can recommend to try and understand how the CLR works and how JIT works is taking a look at SSCLI - an implementation of the CLR based on the ECMA-335 spec.
Have you considered not using C#? Given that the output of the C# compiler is MSIL, it would make sense to develop on a different platform if that is not what you want.
Alternatively it sounds like NGEN does the operation you are wanting, it just doesn't handle putting the entire thing into an executable. You could analyze the resultant NGEN image to determine what needs to be done to accomplish that (note that NGENed images are PE files per the documentation)
Here is a link on NGEN that contains information on where the images are stored: C:\windows\assembly\NativeImages_CLR_Bit for instance C:\windows\assembly\NativeImages_v2.0.50727_86. Note that .NET 3.0 and 3.5 are both part of 2.0.
I have downloaded the csharp grammar project from here http://antlrcsharp.codeplex.com/releases/view/47523, and it runs fine.
But when I add 'output=AST' to the grammar, I get a TON of errors:
I am admittedly new to ANTLR, so I am not sure how to proceed at this point. I would have assumed this type would have existed in the antlr csharp runtime dll, but obviously not. Has anyone come across this problem before?
I ran into this migrating from a v3.2 script generating from the Java tool to using v3.4 with the dotNet build tools.
I was able to figure out (thx to the documentation that comes with the .net VS integration) that the problem with not getting the right return type was because a class is only generated if you have a return type on the rule. Adding a dummy integer return type to my rules that had no return value cleared that up.
There is a discussion of the rule returns in the C# generator and target in the documentation from the C# target page at antlr, follow the link at the top of the page and check out section 4.1.1 "Return values"
About a year ago I did a project with Antlr and ran into an issue where I got tons of errors. As odd as it sounds but by using an older runtime I got it to work. I think I used a dll that had been compiled for the 2.0 .Net Framework.
I do not remember exactly what the error was or what had actually caused it. All I remember is that it solved the issue. I have no idea if this will help in your situation but it's worth a shot if you are stuck.
You are not the first person to have this problem. The patch at https://github.com/antlr/antlr/pull/1 addresses it by providing the missing file. Include it in your source and recompile.
Ok this question is more about understanding what the issues are as I dont think anyone will be able to tell me how to fix the problem.
I am writing a .net 4 application and I have a 3rd party dll ( hasp dongle protection ) that I want to reference.
Visual studio allows me to create the reference fine and use classes contained within the dll within my code.
The first issue occurs when the program is run and the dll is actually loaded. I then get the following error.
System.BadImageFormatException: Could not load file or assembly
'hasp_net_windows.dll' or one of its dependencies. is not a valid
Win32 application
This weblink states how to fix this error. Coud someone expalain what the issue is and why im getting it.
After following this advice I then set the main project build to x86 and I then get another error replacing the other. The new error is:
System.IO.FileLoadException: Mixed mode assembly is built against
version 'v1.1.4322' of the runtime and cannot be loaded in the 4.0
runtime without additional configuration information
This weblink states how to fix the error, but I dont have an app.config in my project and want to avoid having one if at all possible. If someone could explain what the issue is again that would be helpful?
Please let me know if you require anymore information.
The issue is the "bitness" of your application. Once chosen (32 bit or 64 bit) all DLLs within that process need to be the same. This exception tells me that one of your DLLs is the wrong "bitness".
You simply cannot have DLLs with different compilation targets within a given process, a process has "bitness" affinity.
If this is a third party unmanaged DLL then it is very likely 32-bit compiled.
Setting the build output as x86 for the root project (the one that creates the exe) should suffice as this will dictate the process that is created. Any other .NET projects can then simply be Any CPU and will fit in either the 32 or 64 bit runtimes.
Unfortunately for your second issue, the provided link is the way to solve it. There is nothing wrong with having an app.config in a project and you haven't stated why you don't want one.
The answer by Adam Houldsworth notwithstanding, I'd like to add that it is possible to do it without an app.config. However, this requires a tiny bit more work and potentially a proper understanding of COM interop. Whether it's worth the trouble is up to you of course ;).
You can set useLegacyV2RuntimeActivationPolicy programmatically by using the ICLRRuntimeInfo::BindAsLegacyV2Runtime method.
A quick rundown on how to do this is posted in this blogpost. Take note of his warning though, which might make you think twice in using this approach:
This approach works, but I would be very hesitant to use it in public
facing production code, especially for anything other than
initializing your own application. While this should work in a
library, using it has a very nasty side effect: you change the runtime
policy of the executing application in a way that is very hidden and
non-obvious.
I cannot use an app.config file because the assembly is loaded via COM from a native program.
I found the library that supports .net framework 4.0. here. In this scenario, no other solutions had worked for me.