DLL privacy / ILMerge / Dotfuscator

[Andrew E Chapman]

Apologies if this seems to be a silly question, but...

.... is there anything that can be done to stop other people from using your
DLLs? For example, if you have a solution with three projects: two
applications and a class library, when the applications compile you end up
with an exe and a dll. Since VB doesn't implement linking so that the dll can
be embedded in the exe, it must be distributed as is. What is to prevent
anyone from coming along, pulling out your dll, and then using its classes
for their own projects with just a smile and a nod?

I have experimented with ILMerge, which appears to link the files, until the
application runs, then attempts at serialization using the dll's classes fail
(whereas the nonmerged dll/exe combo works fine).

Would dotfuscator be useful in this situation?

[Cor Ligthert [MVP]]

Andrew,

There is not anything to be done at the end to prefent people to recompile
any program.

For doing this as good as can be there are obfuscators

Search for that on internet an in these newsgroup there is a bunch of
discussion about that.
(Especially the newsgroup dotnet.General)

http://groups.google.com/group/micro...rch+this+group

I hope this helps,

Cor

"Andrew E Chapman" <An************ @discussions.mi crosoft.com> schreef in
bericht news:C3******** *************** ***********@mic rosoft.com...

Apologies if this seems to be a silly question, but...

... is there anything that can be done to stop other people from using
your
DLLs? For example, if you have a solution with three projects: two
applications and a class library, when the applications compile you end up
with an exe and a dll. Since VB doesn't implement linking so that the dll
can
be embedded in the exe, it must be distributed as is. What is to prevent
anyone from coming along, pulling out your dll, and then using its classes
for their own projects with just a smile and a nod?

I have experimented with ILMerge, which appears to link the files, until
the
application runs, then attempts at serialization using the dll's classes
fail
(whereas the nonmerged dll/exe combo works fine).

Would dotfuscator be useful in this situation?

[m.posseth]

i use the qndobfuscator works great for me ( and is free ) especially
bevause my project is remotable so i have a method that must be "known" to
the outside world , well in these cases you can set attributes to the method
so it will not be obfuscated , however there is also the possibility to
force obfuscation of certain parts in your code

another aproach i choose is to encrypt all my strings , with sensitive data
( connection strings for instance ) already in the source , so i encrypt the
strings copy them in my program
and decrypt them during runtime , so even succesfull decompiling will leave
another puzzle to be solved , also write some dummy methods and overloads in
your code to confuse the cracker

however 100% safe is impossible
regards

Michel Posseth [MCP]

"Andrew E Chapman" <An************ @discussions.mi crosoft.com> wrote in
message news:C3******** *************** ***********@mic rosoft.com...

Apologies if this seems to be a silly question, but...

... is there anything that can be done to stop other people from using
your
DLLs? For example, if you have a solution with three projects: two
applications and a class library, when the applications compile you end up
with an exe and a dll. Since VB doesn't implement linking so that the dll
can
be embedded in the exe, it must be distributed as is. What is to prevent
anyone from coming along, pulling out your dll, and then using its classes
for their own projects with just a smile and a nod?

I have experimented with ILMerge, which appears to link the files, until
the
application runs, then attempts at serialization using the dll's classes
fail
(whereas the nonmerged dll/exe combo works fine).

Would dotfuscator be useful in this situation?