T
Tim Mulholland
This thread is intended to be more of a discussion thread - because i value
the opinions of the posters in this newsgroup, and especially the MVPs like
Nicholas Paladino and Jon Skeet (thanks to all of you for your help over the
years).
My company has been toying with moving alot of our applications to .NET/C#
(which makes me _very_ happy). I've successfully gotten them to start new
projects using C# and we have been very happy with the results so far.
However, the one primary concern i am running up against in this pro-.NET
push is that my boss, as well as some of the people that wrote the "old" C++
code, doesn't want some of the more important algorithms they use in our
more critical applications to be easily read via a disassembler (even
ILDASM) or even turned back into C# code by some of the applications out
there that are available for that.
I'm kind of at a loss for an answer to them on this, so as of now, i haven't
gained much ground. The possible solutions (and reasons why i don't like
them) that i've come up with so far, are as follows:
1) Obfuscation: Although this makes it more difficult to read, it doens't
completely hide the algorithms/theory of the classes/functions in the
assembly. I've also heard that it has caused people some issues where
assemblies wouldn't execute after being obfuscated.
2) Using Managed C++ and including native C++ lib files: I can't remember if
i ever got this working when i tried it myself, but i do remember it being
quite a pain. part of that came from the fact that i don't like the .NET
implementation in C++ (compared to the C# one) - it seems very kludgy. If
this does actually work, then its a possibility, though not a very clean
one.
3) Creating native C++ DLLs and using interop to get to them from C#: This
was the method i was most successful with, but, partially because of the
complexity of some of the functions/classes our old applications were using
and partially because i'm not all too familiar with marshalling/interop, i
ended up with some not very nice looking code to allow C# to work well with
the functions.
#2 and #3 also just didn't seem like very good options for some of the
thigns i was converting because the algorithms i was trying to hide were
fairly closely tied in with the main operation of the applications (the
parts that would be in .NET).
Basically, i'm curious to find out what others think about all this, and
what others are doing in their own workplaces. I'm big on C#/.NET and i'd
love to get the company moving to as much of this as possible, but i don't
know where to go from here.
Thanks in advance for any comments/suggestions!
the opinions of the posters in this newsgroup, and especially the MVPs like
Nicholas Paladino and Jon Skeet (thanks to all of you for your help over the
years).
My company has been toying with moving alot of our applications to .NET/C#
(which makes me _very_ happy). I've successfully gotten them to start new
projects using C# and we have been very happy with the results so far.
However, the one primary concern i am running up against in this pro-.NET
push is that my boss, as well as some of the people that wrote the "old" C++
code, doesn't want some of the more important algorithms they use in our
more critical applications to be easily read via a disassembler (even
ILDASM) or even turned back into C# code by some of the applications out
there that are available for that.
I'm kind of at a loss for an answer to them on this, so as of now, i haven't
gained much ground. The possible solutions (and reasons why i don't like
them) that i've come up with so far, are as follows:
1) Obfuscation: Although this makes it more difficult to read, it doens't
completely hide the algorithms/theory of the classes/functions in the
assembly. I've also heard that it has caused people some issues where
assemblies wouldn't execute after being obfuscated.
2) Using Managed C++ and including native C++ lib files: I can't remember if
i ever got this working when i tried it myself, but i do remember it being
quite a pain. part of that came from the fact that i don't like the .NET
implementation in C++ (compared to the C# one) - it seems very kludgy. If
this does actually work, then its a possibility, though not a very clean
one.
3) Creating native C++ DLLs and using interop to get to them from C#: This
was the method i was most successful with, but, partially because of the
complexity of some of the functions/classes our old applications were using
and partially because i'm not all too familiar with marshalling/interop, i
ended up with some not very nice looking code to allow C# to work well with
the functions.
#2 and #3 also just didn't seem like very good options for some of the
thigns i was converting because the algorithms i was trying to hide were
fairly closely tied in with the main operation of the applications (the
parts that would be in .NET).
Basically, i'm curious to find out what others think about all this, and
what others are doing in their own workplaces. I'm big on C#/.NET and i'd
love to get the company moving to as much of this as possible, but i don't
know where to go from here.
Thanks in advance for any comments/suggestions!