I wrote a dll in VS2008 that I use in my C# application,but my users don't like the fact they need both .NET framework and VC++ Runtime.
Is there a way I could avoid the 'must-have' VC++ Runtime in my C++ dll?
You can build your dll with the runtime linked statically (/MT instead of /MD - Under properties->Configuration Properties->C/C++->Code Generation->Runtime Library).
You can link the static runtime library into your dll. This way it will always be there and no .dll with C++ runtime will be required.
Like others said, you can statically link, but that will become a nightmare if you ever incorporate 3rd party C++ dlls that are not statically linked (which is almost everything). That scenario will lead to random crashes that will take you forever to debug. The easiest thing to do is to use an installer which hides this from your users. You can use merge modules if you use the vs installer, or install as part of an nsis install. This will make everyone's life easier. Especially yours. There is no reason on should be against installing these anymore than one is against installing the .NET framework. It makes no difference in terms of stability unless you need them and don't have them.
Related
Here it was written that compilers of different versions are applied sequentially to build the latest version of compiler.
I don't want to use binaries provided by Microsoft. I want to have everything be compiled from source codes.
Which repositories I should compile exactly? Do they all have open source licenses?
The runtime and the compiler for .NET 5.0 are open-source. You can start by going to https://github.com/dotnet/runtime. However, building the runtime requires the compiler (which will be downloaded by running the build script). So there's little you can do to avoid getting binaries that were built by Microsoft. If you're afraid that they're fake (and in some way different from what you would get if you directly built everything from source) you'll probably have to go a different way.
I have a .Net add-in and within this I have referenced a DLL I have made in C++/CLI. The DLL was designed against the OpenCV API - so now my .Net application can take advantage of the cool graphics capabilities offered by OpenCV.
The problem occurs when I deploy my add-in to other computers. When the user enacts a part of the program that specifically calls upon my C++ DLL it complains about missing the reference:
I suspect the code does not actually know where the DLLs are located but within my dev environment everything (obviously) works as I will have my environment set up different to your standard build PC.
What am I missing here ?
How can I successfully call DLLs created in C++ from a C# add-in? Bearing in mind add-ins are supposed to simplify the customisation of software like Office etc. This is very important - I have to be able to roll in non-.Net DLLs into my project and my code be able to find them.
My dll is just a plain dll, not a COM compatible dll (maybe it should be?) or should I be decorating my C++ code with __declspec(dllexport) a la https://learn.microsoft.com/en-us/cpp/build/exporting-from-a-dll-using-declspec-dllexport?view=vs-2017
So 2 things
Use Dependancy Walker to identify any dependancies on your dll and the dlls it uses further down the 'tree' hieracrchy. I found 2 that were missing and it wasn't obvious without this useful tool. Don't be overwhelmed with the results it gives you, just take notice of the missing dlls it's complaining about.
Make sure your dll is referenced within your project and not outside of it in some other folder where you built it.
This fixed my problem - in general just make sure your dlls are on the same path as your executable.
I know C++ code runs on local machine directly. I also know that we can compile c# code into native code using NGen.exe. My question is
If we use Native code generator NGen.exe to compile c# code into native code, do we still need the .NET framework to run it?
In fact, if you compile your C++ code into a Windows executable you still need Win32 dlls and other stuffs. Your program cannot run on a CPU that does not have anything besides your program.
The same story for C#. If you compile C# to native code, you do not need the JIT compiler, that is part of .NET runtime. But you still need all other parts of .NET runtime.
For example, the .NET framework with all its classes is not linked into your program. If they would put all required .NET classes into your binary, a simple Hello world app would become huge.
You can use mono to build a C# app that has everything pre-compiled with statically linked framework libraries and does not need a separate runtime.
I wouldn't recommend it, though. Not everything is available for static linking, and one of the things about using a JITter is that it makes your code faster on average across all your deployments, as you can now take better advantage of machine-specific optimizations. It's also not something that even mono is set up to do out of the box.
Yes, you need the framework because the libraries your app use come from the framework.
When you use NGen not just your code is compiled on native code, chunks of framework code are 'nativized' too, just the right parts your apps use.
All this doesn't change your assembly (exe or dll) phisical bytes, this compile the IL to native and store this native bytes in compiled assembly cache.
References in compiled assembly cache still needing some framework components, specially to framework core wich is native code from the beggining.
Quite simple question, and I really wanna know the reason (the real reason) behind this. Say you want to distibute a .NET app to computers without .NET installed (not even 1.1). Why can't we just include mscorelib.dll & others with out app?
Is it because CLR must be installed in some way, to gain JIT capabilities for intepreting IL?
I know this is quite meaningless question nowadays since every system has a minimum of .NET 2.0, but I still wonder :=)
Well, as you already said, the assemblies alone are useless.
You need the runtime environment, including the jitter, type loader, garbage collector etc.
.NET is a Just In Time interpretted langauge. Your assemblies don't compile down to a binary executable.
Therefore you need to have the .NET runtime installed so your code can be interpreted at runtime. Without it...your app isn't going to be doing much of anything.
Installing the libraries and the CLR also allows for shared assemblies. Do you really want hundreds of copies of the CLR running loose on your machine? I like the fact that I know certain things will be available for my application. Much better than having to worry about… Did I compile for 1.4.5 or 1.4.6 version of the runtime... maybe it was even 1.2.5 (JRE can be a pain)
Also there are many parts of the .Net Framework that are just managed wrappers over unmanaged APIs. As well as tons of other assemblies that you use but are not directly referenced. (see mscoree.tlb and many others)
Am I able to embed the .net runtime so that .net is not required on the host operating system? I was looking at doing this with Mono by looking here: http://mono-project.com/Embedding_Mono but seems to allude to using external modules to accomplish this. My goal is to have one single executable with no installed .net runtime. I do not know how this would be configured in my application to compile the native code, link the mono runtime- as well as compile the C# code and link that as well?
You can now statically compile Mono assemblies as was just demonstrated at PDC. The purpose of doing this was to allow .Net applications to run on the iPhone, but this should work anywhere.
There are some limitations to this; obviously, it can't depend on runtime-generated code, so Reflection.Emit is out.
Third-party solution i've used with much success: Xenocode
This is not currently supported, and AFAIK there are no plans to change that status.
There are some third party tools out there that try to do this for you, but last time I checked none were very good yet.