I have a project written in C++/CLI. Some of the types there are in managed code, and some are in completely native code. Let's say I have the produced DLL on a machine that dosen't have any version of the .Net framework installed, is there a way that another, native application will link with my "mixed-mode" Dll and use only the native types? I've noticed that the minute I add the "/clr" switch, my Dll automatically depends on several .Net Framework Dlls (mscorjit, mscoree etc.), and when I actually try to use the 100% native types defined in it, the application still tries to load those .Net Framework Dlls (even though I don't use the framework in that part of the code).
So, is it possible to avoid loading those Dlls in such case? (as I see it, the other option is to create another, native project, that will contain all of the native types, without the managed ones).
Thanks
No. When you load a mixed mode assembly (/clr), right after DllMain runs, the .cctor runs and initializes the framework, if it hasn't already been setup for the application.
Without this, there would be a big hit as soon as you called a function that required a managed API. For details, see "Initialization of Mixed Assemblies" on MSDN.
The best option would be to make your native API a separate DLL, and have the mixed mode assembly a separate project, so you can load it separately if required.
Related
When creating a new app in Xamarin Forms I see these two options:
Configure your Forms App
Shared Code:
Use .NET Standard
Use Shared Library
Can someone explain the difference? I looked at the help and I am still confused. I'd appreciate if someone can give me any advice on this. Not sure if it helps but this app is self contained and no code in the app will need to be shared with any other application.
In terms of what you can achieve with both, it is the same. So, in the end, it's mostly a matter of taste.
The biggest difference is that a shared project is compiled into the app itself. It is nothing more than it says on the tin: it's a shared folder that you can use in all platform projects. Using platform-specific code is done through compiler directives.
With a .NET Standard project, you will get a physical binary. It is a project of its own. You can reuse it in other .NET Standard projects, although you already mentioned you won't be using it for that. Executing platform-specific code requires a bit different approach, using the DependencyService.
Seeing that they made a choice to replace the PCL with .NET Standard but keep the shared project points out that the shared project is here to stay for a while. I tend to like the .NET Standard library more. It feels cleaner and forces you to write cleaner code. Also, .NET Standard isn't going anywhere soon and if you decide that code should be reused down the road, you have the ability to.
A good overview, together with pros and cons can be found in the Microsoft Docs: https://learn.microsoft.com/en-us/xamarin/cross-platform/app-fundamentals/code-sharing
An mixed-mode C++ application is built using VS2012, it references the managed DLL Noesis.Javascript.dll (which I believe was built with VS2010) which in turn links at runtime with msvcr100.dll.
I have observed a crash which seems to show the code within the Noesis.Javascript.dll calling library functions from VS2012's msvcr110.dll.
Is it possible to run a single process using two different versions of the C++ runtime libraries or is what happening here the likely cause of the problem? What is the alternative?
As mentioned for instance in this answer, it is practically impossible to combine these binaries. The crash is probably caused by the incompatiblity.
You could try the following: Project Properties -> General -> Platform Toolset: Visual Studio 2010 (v100).
It is possible to use both runtime DLLs in the same process, but to do so safely requires great care to ensure that no objects from one are used in the other.
What is the difference between a LIB and DLL? I have read plenty of posts on here about it and there are some good, clear answers however I am writing to ask for clarity on one matter.
Is it better to use a LIB (static link library) when there is only one user e.g. for a administration application client installed locally on the PC? and is it better to use a DLL (Dynamic link library) when there are multiple concurrent users accessing a classic asp application that uses vb6 classes?
A LIB file generally corresponds to a static library, which means that all of the library code that your application uses is compiled directly into your application.
A DLL file represents a dynamic library that your application links to, and then when you want to use code from the library, you call into it dynamically while your application is running.
Of course, you'll frequently see a LIB file for a dynamically-linked library as well. That file contains "stubs" that the linker uses to implicitly link to the DLL.
The obvious benefit of a DLL (dynamic linking) is that one DLL with common functionality can be shared with multiple applications that use that same functionality. Bug fixes can be made in a single place, and only one component has to be updated in order for all of the apps to take advantage of those fixes.
If you only have a single application that uses your code, there's little reason to put it into a DLL. Multiple users on multiple computers are going to have to have their own copy of the DLL anyway, so there will be no code sharing going on in that situation.
All of that said, I have no idea what this question has to do with VB 6. To my knowledge, you can only use it to create ActiveX DLLs (which have a different use case) and it can't create static libraries at all.
In my work we have VS2008.
Some partners in the project I work, use VS2010 (can't use VS2008)
They have to build a dll based and I have to use that dll in my framework...
I managed to build the main app and link the dll's.
the app starts, and objects from the VS2010 dll's are created,
but the app crashes when i try to delete these objects...
Windows has triggered a breakpoint in app.exe. This may be due to a
corruption of the heap, which indicates a bug in app.exe or any of the
DLLs it has loaded.
Have you any ideas on how to fix this?
Your co-workers' DLLs are linked against VS2010's runtime library. Your code is linked against VS2008's runtime library.
When you call some function from the VS2010 dll to allocate a new object, it will be allocated on that library's heap. When you call "delete" on that object, VS2008's runtime library will try to free it from its own heap. Since they're different, you get that error.
If you're going to mix runtimes like that, you need the VS2010 dll to expose free()-style functions (not just C++ destructors) for each type. There are other things you should be very careful with when mixing runtime libraries like that, such as using STL containers, or any sort of "copy-on-write" objects. In general, it's easier to avoid it.
Object that was allocated in dll or in an exe should be deallocated in same place. You need to talk about that with your partners. For the goal may be used overloading of allocating and deallocating operators http://www.cprogramming.com/tutorial/operator_new.html
I have an existing project created using C/C++ under a development environment.
Currently we want to facelift the existing form using a Window Forms application but the problem is the existing project is using Common Runtime Library = No /CLR and Runtime Library = /MTd.
But the a Windows Forms application is using Common Runtime Library = /CLR and Runtime Library = /MDd.
Please advise if it possible to use a Windows Forms application to create a form in the existing project?
Is there any tutorial regarding this?
The comment from MSDN was:-
Caution Do not mix static and
dynamic versions of the run-time
libraries. Having more than one copy
of the run-time libraries in a process
can cause problems, because static
data in one copy is not shared with
the other copy. The linker prevents
you from linking with both static and
dynamic versions within one .exe file,
but you can still end up with two (or
more) copies of the run-time
libraries. For example, a dynamic-link
library linked with the static
(non-DLL) versions of the run-time
libraries can cause problems when used
with an .exe file that was linked with
the dynamic (DLL) version of the
run-time libraries. (You should also
avoid mixing the debug and non-debug
versions of the libraries in one
process.)
http://msdn.microsoft.com/en-us/library/2kzt1wy3(VS.71).aspx..
The simple answer is no. A more accurate answer is kind of, but you probably wouldn't want to.
It is possible to use Windows Forms (i.e. managed code) for your user interface and something else (e.g. non .NET/unmanaged code) for your domain logic. However I'd guess that if you're asking this question then that is going to be a bit much for you to do at the moment.
I suggest that you create a user interface with Windows Forms and then have that user interface call a native C/C++ DLL. Google for PInvoke on how to call an unmanaged dll (C/C++) from managed (.NET) code.
If you did that then you would be much better positioned to answer this question.
My company software often has to have modules which mix managed and unmanaged code and user interfaces. What we do is to separate the modules into their own executables and expose the functionality as COM localserver objects. This way, the unmanaged code can have a user interface written in managed code.
However, you need to do alot of plumbing to get it to work. We do it this way because our applications have been deployed in the field for years and it will take years to give the entire program a makeover into .NET