2

Consider the following situation:

I have developed a DLL file DCore. Afterwards I developed a DLL file DCustomer which uses methods from DCore. Now I want to distribute DCustomer as DLL for a customer and make sure to hide all functionalities of DCore, so that the customer can only access the functionalities of DCustomer.

How can I hide the functionalities of DCore when creating the DLL file DCustomer?

Geeky Guy
  • 9,229
  • 4
  • 42
  • 62
John Threepwood
  • 15,593
  • 27
  • 93
  • 149
  • Don't listen to people who say you can't do that. The good news is that you can. The bad news is that [your question is a duplicate](http://stackoverflow.com/questions/96732/embedding-one-dll-inside-another-as-an-embedded-resource-and-then-calling-it-fro). – Geeky Guy Sep 09 '13 at 20:36
  • @Renan thank you for pointing me to the other question. Isn't there also a possible solution with friend assemblies or signed assemblies? – John Threepwood Sep 09 '13 at 21:03
  • @JohnThreepwood I don't see any mention of either in the marked answer. Anyway, I haven't tried anything myself - I just knew this has been asked again and again in SO, so I pointed that out. You may want to try the tools suggested in that question, maybe you'll find something that'll do the trick for you. Good luck and happy coding :) – Geeky Guy Sep 09 '13 at 21:10
  • You need to define what "hide" means. As @Jon pointed out as soon as assembly is in user's hand in any shape (including obfuscated/hidden as resource/protected with `InternalsVisibleTo`) user can call methods/look at code... – Alexei Levenkov Sep 09 '13 at 21:43
  • @AlexeiLevenkov "Hide" in the sense that the customer can only access the methods in `DCustomer` and none of the methods in `DCore` (even if they are public). – John Threepwood Sep 09 '13 at 21:51
  • Not enough info - you need to think why simple text warning "usage of XXXX assembly directly is not supported" is not enough. Warning would stop normal users, but you need to know how far you want to go with discouraging to look into/use of internal assembly. – Alexei Levenkov Sep 09 '13 at 22:01
  • @AlexeiLevenkov counterquestion: How far can I go? I would like to discourage as much as possible with a reasonable amount of effort. – John Threepwood Sep 09 '13 at 23:05
  • Making everything in DCore internal and using `InternalsVisibleTo` is probably only cheap discouraging solution... @Renan suggestion to make DCore resource file and extract before execution will be pain to sort out runtime dependencies (but slightly more discouraging for users)... Obfuscation and more complicated approaches should be relatively easy to find by searching for "obfuscation"... – Alexei Levenkov Sep 09 '13 at 23:22

1 Answers1

0

There is nothing much you can do about it.

But do check out StrongNameIdentityPermissionAttribute

I would also request you to check out this Thread

Community
  • 1
  • 1
Rahul Tripathi
  • 168,305
  • 31
  • 280
  • 331