I'm tasked to replicate functionality from an existing application. This application relies on .NET managed assemblies accessible from C#. I can import those DLLs in my new C# project but there is no documentation on how to use them.
Yes, this is labeled as an "SDK", but does not contain examples or documentation. Any pointers on how I should proceed?
I thought about creating stub assemblies and monitor their usage from the original application but this involves a lot of code. Is there maybe a tool could do it for me?
Using the Reflector is the best way to do that. You can see what calls what and examine the dlls in a good and easy way.
You can also try Cecil
They both are great tools for inspecting managed dlls
Related
I have a rather large legacy nmake (Win32) project that creates a static library from native C++ code. I need to use this library in a C#/.Net application. In the past after much effort I had been successful at wrapping the static library in a managed C++ library, which I am then able to reference in a C#/.Net application. However, after receiving updates from the developers of the nmake project, and having gone through an many upgrades on my own build machine in the meantime, it is no longer working.
I am however able to import the cpp and header files of the nmake project and build it to a Win32 static library in VS 2010, by setting all of the preprocessor constants in the build properties. I set the build configuration type to DLL, and then try to add a reference to the Win32 output in my C#/.Net application hoping to use P/Invoke down the road, and it fails with a message "A reference to MyLibrary could not be added."
Is there a way to build the Win32 library so that it can be referenced by the C#/.Net project and so that I can use P/Invoke?
Is there a way to build the Win32 library so that it can be referenced by the C#/.Net project and so that I can use P/Invoke?
If you want to directly reference the library, you'll need to build a C++/CLI project using your library, and make managed wrappers.
If you want to use P/Invoke (which is a separate concept), you can make exports with a C API, and call those directly via P/Invoke.
The two approaches are both valid, but completely different in terms of implementation (C++/CLI vs. C API wrappers) on the native side, as well as used differently (directly referenced for C++/CLI vs. P/Invoke via [DllImport]).
You can use SWIG to generate wrappers for your code. SWIG is a very powerful tool and worth taking the time learn. It creates wrappers for a number of languages including Python, C#, and Java so if you get it working with one language it is fairly easy to use in other languages as well. It will generate all the wrapper code for you, although you will probably need to do some work with type. You use swig to create a special DLL that SWIG generates code for and then used supplied C# code to access the DLL without needing to deal with managed C++ assemblies which can be a nightmare to deal with.
http://www.swig.org/Doc2.0/SWIGDocumentation.html
Edit: my explanation may not be that clear and the docs are pretty overwhelming, take a look at the "What is swig?" section here to get started:
http://www.swig.org/Doc2.0/SWIGDocumentation.html#Introduction_nn2
What is the best pathway to achieve this?
I know that VS2005 contains an upgrade mechanism. Do any later versions of VS contain this?
Microsoft has devoted a site to VB6->.NET migration.
They recommend a Free tool from ArtInSoft.
However I'm not sure I'd like to maintain a .NET application written in VB6-style. But on the other hand a tool could give you a good start and you can refactor the result where the tool does not produce code of your liking.
In the latest release of Visual Studio, the VB6 Migration wizard is now missing from the IDE.
A good external tool to perform a migration is VBUC .
One way to do this, which was used successfully in one of my previous teams, is:-
use the free Microsoft tools for upgrading from VB6 to VB.NET (e.g. http://msdn.microsoft.com/sv-se/vbrun/ms788233)
compile the resulting code into assemblies
decompile the assemblies into C# using a tool such as .NET
Reflector, ILSpy, etc.
cover the code in unit tests
refactor until the code is managable (the initial code is likely to
be quite ugly)
When I'm writing a C# (or any .NET programme) I use methods and classes. Most of the code I use is calling methods from the .NET classes. Is it possible (purely out of curiosity) to see the actual source code for these classes?
I know MSDN has full listings of the classes, their properties and their methods. But I would like to see the code.
Yes, it is:
Browse the .NET Framework source code online, with search and navigation powered by Roslyn.
See details at the .NET Framework blog...
Yes it is possible. See here for more info:
http://weblogs.asp.net/scottgu/archive/2008/01/16/net-framework-library-source-code-now-available.aspx
You can also run a disassembler (such as the one in Reflector) over the base class libraries and view code that way, if you don't want to configure your dev environment. You won't get real variable names or comments, but for isolated viewing this can be easier.
Yes, Microsoft has released the source .NET.
This article should help get you started.
The link mentioned in the accepted answer (https://referencesource.microsoft.com/) only contains .NET source up to version 4.8. Development is now done on Github, where you can find (literally) up-to-the-minute versions of the source files.
The dotnet Github organization (the .NET Foundation) has many of the repos relating to .NET, including core, the CLR runtime, aspnetcore, and a bunch of others. Most of the source code is organized into Visual Studio projects and solutions, so you can import them easily.
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.
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.