Preventing COM Name Mangling - c#

I am trying to write a replacement for a VB6 dll that is referenced by another VB6 in c#.net.
For now we can only work on the later and I am having some success with this. Except I have run into a problem.
My Enums are being mangling resulting it being called 'A1BACSTrans_BACSAU' instead of the expect 'BACSAU'
the legacy code will (obviously) no longer compile.
Can this be prevented? if so, how? I have heard of modifying the IDL but I can see no references in their to a mangled name only unmangled...
Thank you in advance!

Guys, I have been discussing this over at c-sharpcorner also and although I mainly arrived at the solution myself I have document it there
http://www.c-sharpcorner.com/Forums/Thread/111642/preventing-com-name-mangling.aspx
Basically changing the IDL is the way I found to do it.
I'd love to know if there is a way to do it in code, maybe an attribute but if there is a way I don't know it!

Related

how to reference imagesearch.dll to c# winforms?

I can't reference ImageSearch.dll in my project. I've been trying for days and can't get any further. it seems to me that i'm the only one with this problem and i don't know what to do next. Is it possible to reference a .dll manually, for example via lines of code? It's nerve wracking and need this or a similar feature.
I keep getting the following error:
Could not add a reference to imagesearch.dll. Make sure the file is accessible and is a valid assembly or COM component.
enter image description here
Hope someone can help me...
That message is telling you that the dll you're trying to reference is something that .NET doesn't know how to work with automatically. This means it has no idea what functions are in the dll or how they work. So, if a dll isn't a .NET assembly or exposed via COM, then you can use PInvoke (Platform Invoke).
Don't add the dll as a reference to your project at all, instead add it as a content file that gets output with the rest of your compiled code. Getting PInvoke to work with an arbitrary DLL can be quite complicated, so be prepared for some headaches. There's an entire website with examples of how to pinvoke for all sorts of libraries at http://pinvoke.net/ that will give you lots of ideas.
Then you can call methods in the dll by doing something like:
// Import ImageSearch.dll (containing the function we need) and define
// the method corresponding to the native function.
[DllImport("ImageSearch.dll"]
private static extern int FindImage(string imagePath);
Obviously I have no idea what imagesearch.dll is or does, so I have no idea what the actual PInvoke function should look like, you'll have to figure that out from the dll's interface.
https://learn.microsoft.com/en-us/dotnet/standard/native-interop/pinvoke

Obtain assembly from executable

I am on a hunt to write a program that will be able to read assembly code from a specified .exe . What i am trying to do is to read the assembly code of a executable, in order to find instructions that i can replace with equivalent instructions, in order to obtain different byte code.
This is generally called a source scrambler / signature scrambler, that modifies assembly code in order to obtain different byte code which results in different signatures.
I was reading about the Assembly class in C# , but did not find anything that could return something like a IEnumerable that contains assembly code from the .exe
Is there anyone that can educate me on this? Is this even possible? Different approaches?
.NET does not really deal with Byte Code. All .NET Programms are turned into somthing called MSIL that is executed by teh .NET Runtime and only then turned into bytecode. The whole process is very similar to how JavaBytecode works.
As a result you get full access to the names of anything. You can even use .NEt Executeables like a .DLL file. But replacing stuff is not easy, outside of inheritance or replacing of the files.
The kind of bitwise manipulation you propably need, requires working with naked pointers. And the .NET Developers went out of their way so you would no ever have to use naked Pointers. You can still use them using Unsface code, but as this sounds like the primary use of your programm you are propably better of starting with something like native C++ instead. Really anything taht uses naked pointers as default, rather then a fallback.

Accessing VB functions such as (DateAdd, DateDiff) in a C# project

I am converting a lot of VB.NET code over to C# and there are a lot of VB functions that C# doesn't have such as DateAdd and DateDiff. Can someone tell me the libraries I would have to reference in order to have access to these functions in my C# code if it is even possible. I already tried adding a reference to Microsoft.VisualBasic and it doesn't work.
Time is a factor here which is the only reason I am looking into doing things this way. I want to leave the code in place as much as possible.
Opps it actually is in Microsoft.VisualBasic.
You have to access it like this:
Microsoft.VisualBasic.DateAndTime.DateAdd()

Is there any C# decompiler that can show the coding almost identically to how it was written?

I've been using reflector to decompile a couple simple c# apps but I notice that though code is being decompiled, I still can't see things as they were written on VS. I think this is the way it is as the compiler replaces human instructions by machine code. However I thought I would give it a try and ask it on here. Maybe there is a decompiler that can decompile and show the coding almost identically to the original code.
That is impossible, since there are lots of ways to get the same IL from different code. For example, there is no way to know if an extension method was called fluent-style vs explicit on the declaring type. There is no way to know if LINQ vs regular code was used. All manner of implicit operations may or may not be there. Removed code may or may not have been there. Many primitives (including enums) up-to-and-including 4 bytes are indistinguishable once they are IL.
If you want the actual code, legally obtain the original code.
Existing .Net decompilers generally decompile to the best of their ability.
You appear to be asking for variable names and line formatting, which for obvious reasons are not compiled to IL.
There are several. I currently use JustDecompile found here http://www.telerik.com/products/decompiler.aspx?utm_source=twitter&utm_medium=sm&utm_campaign=ad
[Edit]
An alternative is .NET Reflector found here: http://www.reflector.net/
I believe there is a free version of it, but didn't take time to look.
Basically, no. There are often many ways to arrive at the same IL code, and there's no way at all for a decompiler to know which was used.
No, nor should there ever be. Things like comments and unreachable code would just add bloat with absolutely zero benefit. The very best you can ever do is approximate the compiled code.

How can I get close to non-nullable reference types in C# today?

I've read many of the non-nullable questions and answers. It looks like the best way to get close to non-nullable types in C# (4.0) is Jon Skeet's NonNullable<> hack.
However, it seems that C++/CLI has solved much of the problem by supporting managed references: Foo% (instead of native C++ Foo&). The compiler makes this work by adding modreq(IsImplicitlyDereferenced) to the argument. Trying to call such a function from C# results in:
'<FunctionName>' is not supported by the language
Is there anything better then NonNullable<>?
Is there any way to (reasonably--i.e., w/o using reflection) call a C++/CLI method Foo::Method(Bar%) from C#?
[edit] It seems there is currently nothing better than NonNullable<>...I wish I would have gotten some comments on the C++/CLI stuff as it already has at least a partial solution.
I've run into this a few times...I've yet to find anything better than Skeet's solution. It's solved all the cases I've come across, so I have to give it my vote.
I agree it's a bit of a hacky situation that we have to resort to that...but his fix does solve the problem.
Yep, spec#: http://research.microsoft.com/en-us/projects/specsharp/
-- Edit: I just noticed you said C# 4.0; I'm fairly sure Spec# doesn't support that version. Nevertheless, it's worth a review.
You may also be able (I think) to check at a slightly later stage then compile, via a rule in Gendarme: http://www.mono-project.com/Gendarme (assuming that runs against 4.0)

Categories