Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
I'd like to know how to inject a C# DLL into a Unity process. Since Unity hosts a CLR (as it runs mono MSIL), I'd imagine I could play around with reflection.
So how would I inject a .NET DLL into a .Net process, and what can I do in terms of reflection once I'm in there?
For example. Say i have a game that uses unity3d as the engine, with most of the code writtin in C# (that doesn't matter since unity seems to compile unityscript to .net anyway). I want to extend this already written codebase with my own code.
Typically in a normal native process you would start reversing the code, finding pointers and data structures as they appear in memory, gaining an understanding of the code as you go along. Then writing the same structures in your code, obtain rwx access to that processes memory (typically by injecting a dll into that process) and then going to town.
Since unity uses .net however, i was wondering if there was a better way. I'd like to leverage the reflection capabilities of the .net framework. For this I think I'd need to get my code injected into the unity process. From there i don't know how a workflow might be.
Long story short: I'd like to inject a DLL, with a payload written in C# (hopefully using reflection instead of pointers), into a foreign process (i don't have control over it at compile time), and mess around with the processes internal classes and functions.
One option is the .cctor function (module initializer), which does NOT run on assembly load, but rather the first invocation into your dll.
Previously, I thought this was the earliest you could get with .net, but apparently I'm mistaken:
There's a horrible, nasty hack that lets you run a DllMain in .net - C# equivalent of DllMain in C (WinAPI)
This is certainly not something that was intended by the creators of .net. Be careful when using it.
This gets your code running, and once in, you can invoke System.Reflection like normal and do whatever you want.
Drop the DLL into an asset folder
Assets/Libs/MyLib.dll
Open any CS file and in the MonoDevelop solution add the reference.
When you quit MonoDevelop Unity will refetch the solution file and import the dll's reference.
You can now use your library from Unity code that you write in MonoDevelop just as normal.
There will be no difference between your code and any other API like System.IO.
Pay attention to the .NET framework versions, don't mix code.
To be safe, use .NET 2.0. ...wait... I don't remember but it should be 2.0... don't quote me on that.
Once you're there you can do everything as normal.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I'm trying to make a console program in C# that is independent from using System or any other libraries, that includes Console.WriteLine();. I'm making an SDK written in C# (almost like what Unity 3D does). However I don't know how to make a custom text printer. I've found no articles on the web or Stackoverflow questions related to what I want to do. There has to be someway of doing this, or Console.WriteLine(); wouldn't exist.
Here is my code so far, but I don't know how much it will help:
public static class GPrint
{
public static void Print(string str)
{
}
}
I've explored almost all of the obvious stuff like string.something() and str.something(), but there seems to be nothing related to printing a string on the screen.
Is there any way I can make a simple Console.WriteLine() clone without using the provided System namespace?
Thanks in advance!
System.Console, an abstraction over stdin/stdout is so inherent to processes that the .NET team decided to incorporate it into the common object runtime library (mscorlib).
In other words, letting a process receive input and emit output over the standard streams is so ingrained into the runtime and the base class library, that it it not possible, or at least not feasible, to have one without the other.
It's not like you can run a .NET console application omit loading the .NET Framework altogether, just because you're not using System.Console or any other class from the System namespace.
See also Hans' answer in Is mscorlib.dll/mscoree.dll loaded when .NET application runs:
Technically it is possible to not get mscorlib.dll loaded [...] Practically that only works if you provide a substitute
If you're not looking to omit mscorlib altogether, but really just are curious about writing to the console without using System.Console, see MSDN: Console Functions. You'll have to use Platform Invoke. This will come at a price though: your application will then only run on Windows, unless the platform you're running on substitutes the relevant DLLs.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I need to create some functionality in our large C# software package that will use .NET DLLs from a third party software package. Not all of our customers are going to use this package. If I add a reference to those DLLs in Visual Studio I can access the objects I need from them, but I assume that will break the build for other developers in my company who won't have this third party package installed.
What is the correct approach for me to be able to access this third party functionality without breaking things for customers and developers who won't use that package? Do I need to address this by creating my own DLL as a layer of indirection? Do I need to dynamically load the third party DLLs at runtime?
To my understanding, a .NET DLL is not loaded by the application until it is actually needed. This means if the DLL is referenced, but no code branch making use of it is reached, it is not required to be present. Perhaps it is not necessary to implement something in this case.
That being said, it is possible to use a technique termed 'hot loading', which means using reflection to explicitly access types contained in a .NET DLL. The technique is discussed in this question.
First, check if it has already been loaded; if not, check if the .DLL exists, and if so, dynamically load it with System.Reflection.Assembly.LoadFile. The reason you want to check if it has already been loaded is because the dynamic loader will often waste memory by loading additional instances.
It will be a bit more work, but by handling this dynamically, you can enable/disable functionality in your application that requires the assembly based on whether it is present, which will minimize unnecessary error reports from people trying to use it when it is not there.
Be careful in referencing the assembly when it is not there; although .NET will usually dynamically load only when an assembly is needed, newer versions are getting more aggressive in how they load, to prevent startup delays, so even if it works now (and that depends on the overall configuration), it may not work in the near future.
It looks like I will be using dynamic loading as described enter link description here. Props to Alberto for showing how to use the dynamic keyword with his answer.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
I'm supposed to work with Open CV, which can be programmed in C++ and deploy it in a .NET graphic interface application. I'd really like to work with C # for the interface traits.
What's the best approach for this?
I know of two ways that C# and C++ can be used in the same application.
The simplest way works where the components to be written in C++ and C# can be separated such that one component relies on the other, but they are not mutually dependent. In this case just create two assemblies, one in C# and one in VC++, and reference one from the other. This is the simplest way to do it, not least because it is supported in the UI of Visual Studio.
However, that approach will not work if there is a mutual dependency, ie, class A needs to know about class B and class B needs to know about class A, where class A is to be written in C++ and class B is to be written in C#. It is still possible to write the classes in different languages like that, using a lesser known feature of .NET called multi-file assemblies, or netmodules.
See How to: Build a Multifile Assembly and Multifile Assemblies for instructions. It is useful to remember that the C++ compiler is generally more clever than the others. I seem to remember the procedure was to get C# to compile its half to a NetModule, then pass that to the C++ compiler and linker which was capable of linking it to the C++ parts and creating the final assembly.
An alternative approach, if you only intend to write a small amount of C# code, would be to learn the VC++ syntax for the .NET features you want to use and avoid C# altogether. VC++ can declare managed interfaces and types just like C# can, and if you will not be writing much actual code in C# then this might be easier.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 5 years ago.
Improve this question
I am coming towards the end of a project that I created in C#. Unfortunately, the target hardware only comes with compilers for C/C++. My dad is an embedded programmer so he will be making the necessary code to integrate with the hardware, but in the meantime I need to find a way to translate the language. Free translators are a very high preference as I am extremely tight on funds at the moment.
While I am not fluent in C++, with a dirty translation I should be able to figure out most of what is required to make it run.
Edit:
The target platform is mbed Microcontroller
Don't. This will not work.
C# has a garbage collector. C and C++ don't. You will have to rethink how you allocate objects and release them in C++.
Chances are, since you already have completed the project, rewriting it in C/C++ will be quite easy. You already understand the problem and have expressed it once before.
There is no 1 to 1 mapping from c# to c++. The programming model and platforms are very different at the lower levels. Take memory management for example.
Your best chance is either to rewrite your application or try to get .NET Compact Framework or .NET Micro Framework to run in the hardware.
Edit:
Note that at least the .NET Micro Framework has a porting kit if your hardware is not supported.
Since design is half the battle in application development, your C# prototype should serve you well, but you are unlikely to find a suitable automatic translation tool. If you have not made heavy use of the .NET class library, especially those parts that relate to the underlying OS API, C# should be easily manually translated to C++. The code body syntax and semantics are very similar; it is the enclosing structural elements such as class definitions that are more different.
The required effort depends on the size of the application code, but much of that is mechanistic. The biggest difference being that you need to be more careful with memory management in C++ since there is no automatic garbage collection.
Learn C or C++. There are no alternatives.
Both languages are radically different from C# and .NET, and automatic conversion is not possible. (and if it were, it certainly wouldn't allow you to "figure out most of what is required to make it run". It would be completely unrecognizable code, that'd be impossible to read or extend.)
In order to write a working C or C++ program, a C or C++ programmer needs to write the code. The good news is that it doesn't have to be that difficult. You don't have to learn every corner of the C++ language. But you do need to learn the basics.
If you're looking for the quick and dirty way to get off the ground, learning C might be a better option, because the language is so much smaller and simpler. But C++ is doable too. Just don't think you can get away with reading a 15-minute online tutorial.
There are no translators.
The .NET Micro Framework has been ported to a Phycore LPC3180 (NXP) platform that is not to dissimilar to your board so it can be done but you still need to port the .NET framwork to your platform.
It is unlikely that you will be able to use Mono AOT unless you are going to port Meamo to to your mbed board.
Any porting would require you to be able to program C code.
The best and fastest way forward would be for You to learn C++.
The differences between C++ and C# are not to big once you get going with C++ and understand the differences. You also going to have to use the mbed library for your hardware control and communications instead of what is provided by C#.
The C# code was a good prototype to debug your program design but it is not going to help you on the target. Now that you understand the problem it should not be to hard.
I'm not sure how you got this far without realising that the target platform couldn't run .NET, but it might be worth seeing if Mono's Ahead-of-Time compiler is able to output to your target platform.
At least then you wouldn't be throwing out (months of?) code.
Since you wrote the application in a garbarge-collected language, the fastest way to port this to an mbed platform should be to port the application to a garbage-collected language which runs on mbed.
I haven't tried it, but eLua is supposed to have a preliminary port which runs on the mbed platform, and Lua is fairly simple to learn.
http://mbed.org/users/jsnyder/notebook/elua-preliminary-port/
If you can get your dad to bring up eLua on the mbed platform, I suspect you could do the conversion fairly easily compared to trying to convert your application to C++.
Port the code manually, and as you do, you will learn C++. :D
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
Is it possible to do CAD/CAM software without having to use C++? My company developed their software with c/C++ but that was more than 10 years ago. Today,there is a lot of legacy code that switching would force us to get rid of but i was wondering what the actual risks are. We have a lot of mathematical algorithms for toolpath calculations, feature recognition and simulation and 3D Rendering and i was wondering if C# can handles all of that without great performance loss.
Is it a utopia to rewrite such algorithms in c# or should that language only deal with UI.
We are not talking about game development here (Halo 3 or Call Of Duty) so how much processing does CAD/CAM really need?
Can anybody enlighten me on this matter? Most of my colleagues are hardcore C++ programmers and although i program in c++ i love .NET but i am having a hard time selling .NET to them other than basic UI. Does it make sense to consider switching to .NET in such a field, or is it just not a wise idea?
Thank you
If you have a lot of legacy code that would need to be rewritten, I don't see it making business sense to switch to a different language. Even if there were gains to be had from using a different language (which is questionable), the cost of testing and debugging the new code would more than overcome them. You also have a development team that are experts in C++. There would be a big productivity drop while they came up to speed on the new language.
C# Can interop with C++ code. You can start writing new code in C# and have it call existing c++ code when needed. It wouldn't have to be just for UI. Look into C++/CLI and the C# Interop methods for information on how to use existing c++ code with new C# code.
Also, I asked a similar question here:
C# Performance For Proxy Server (vs C++)
CAD/CAM applications are fairly calculation intensive, and speed will definitely be one of the criteria for selecting a package, so I would be wary of moving to a slower language.
You need to think very carefully about the reasons for switching language. Is it because you don't like C++, or because C# will bring real benefits. It is quite likely to slow your application down. Check out the C++ C# speed comparisons.
Computer Language Benchmarks Game C++ vs C#
In my humble opinion, you'd be better off keeping all of the toolpath calculations in C++, and if you really must move any code over to another language, move it over to a scripting language which the user can easily edit, without re-compiling.
I use CAD/CAM applications every day at work, and there are a number of things in the UI which get on my nerves. They would be simple fixes if only I could get at the source.
If your company makes a CAD/CAM application which has a UI written in a scripting language which I can tweak (Lua, Python etc), I'll buy a copy.
Hugo
Have a look at pythonocc. Its provides you with a python module that wraps the OpenCASCADE CAD kernel. OpenCASCADE is the sole industry strength open source kernel I'm aware of. Nice features are STEP and IGES support and the ability to generate FEM meshes from BRep data.
Another thing you need to consider is platform independence - if there is a possibility that you/you company need to migrate your CAD software to Linux/Unix (Of course, for bussiness decision), it will be quite painful. Currently, even C++ with MFC/Win32 calls gave us many headache...
The Open Design Alliance library is cross-platform. They have recently introduced a beta of the .NET version of their library. See my answer to Open source cad drawing (dwg) library in C# for more details.
Having said that I concur with the other answers here - if it ain't broken, don't fix it, both the code and the coders. MSFT still use C++, as does the ODA - their codebase originates in C++ & is wrapped for .NET.