|
Father Christmas wrote: I'd hate to see people not using the site for fear of humiliation.
Well said!!
|
|
|
|
|
Hi
I would like to change the output of my project that include exe,DLL and obj
I see that I can change the exe path at project->propoerties->build
How can I change also the obj outout such as *.csproj.GenerateResource.Cache,*.frmMain.resources, *.frmTemplate.resources
All the files above create at obj->debug and I wish to change it
Thanks
Ronen
|
|
|
|
|
In the csproj file, add a tag for BaseIntermediateOutputPath under root property group tag. Put the desired path there.
C isn't that hard: void (*(*f[])())() defines f as an array of unspecified size, of pointers to functions that return pointers to functions that return void
"Always program as if the person who will be maintaining your program is a violent psychopath that knows where you live." - Martin Golding
|
|
|
|
|
|
Hi, guys,
OK, my question might sound stupid, but I was googling around and didn't find anything about it 
I was exploring an assembly using the Reflector tool, and I've came across several classes with weird names, say <module> or <privateimplementationdetails>{0DA2D479-FAFD-495A-B33D-A1B079722BAC}.
These do not belong to any namespaces defined in the assembly, so I have a feeling these are auto generated by the compiler.
So, the question basically is what are these classes for and how do I detect those type of classes in code. I guess, if I figure out what are they for, I'll find a way to detect them 
Thanks
Regards,
Lev
|
|
|
|
|
My first thought would be these names are generated by an obfuscator
only two letters away from being an asset
|
|
|
|
|
No, Mark, I built this assembly (debug build) and I don't even have an obfuscator installed
So it's clean
Regards,
Lev
|
|
|
|
|
Hello everyone,
I've got a project and I am making a version 2 of this project. Though still version 1 must be active and used.
So I'm using preprocessor directives to assign the extra parts for the program for version 2. But in this case I have to place a #define VERSION_2 in every file where I want to make a difference between version 1 and version 2.
I would like to know if it is possible to put a #define in one file and use it in another file.
For example:
#define VERSION_2
namespace Prog.test
{
class test
{
#if VERSION_1
doThat();
#elif VERSION_2
doAnother();
#endif
}
}
namepace Prog.chair
{
class chair
{
#if VERSION_1 //does not work, because not defined
setHeight();
#elif VERSION_2 //does not work, because not defined
setWidth();
#endif
}
}
|
|
|
|
|
You can define them in the project properties:
Project -> (Name) Properties -> Build -> Conditional compilation symbols
regards
modified 12-Sep-18 21:01pm.
|
|
|
|
|
Thank you very much! That's all I needed 
|
|
|
|
|
I would think the best way to accomplish backwards compatibility is to derive a new class from the original, and then the calling assembly can use whichever version it wants. No need for compiler directives at all.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
Why not using branches on a version control system (like SVN)? Sure, this makes things a bit complicated but should keep the code pretty clean.
regards
modified 12-Sep-18 21:01pm.
|
|
|
|
|
0) He's talking about making an assembly compatible between versions. Source control is completely out of context.
1) Just because you *can* make it more complex, doesn't mean you should.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
Hi all.
Hopefully someone will be able to give some pointers. I've written a small COM object using C# which is basically a form containing a axwebbrowser object.
The problem i'm having is that when i instantiate my COM object using VB script i am unable to get the web browser to accept any keyboard input. I can click links on pages and navigation works fine, but I can't get it to accept any kind of keyboard input.
|
|
|
|
|
i used some 3rd party tools and mine also in an app, now i want to secure those dlls. I used some tools and software those merge the assemblies with exe but i dont like that way because it slow down the startup of app, bugs and many other reasons. Therefore, i thought to copy all the dlls in users' system32(64) directory or any other and it can be done but how to change the path of dlls, mean how to tell my app that read the dll from that directory instead of reading from its own. Any idea ?
TVMU^P[[IGIOQHG^JSH`A#@`RFJ\c^JPL>;"[,*/|+&WLEZGc`AFXc!L
%^]*IRXD#@GKCQ`R\^SF_WcHbORY87֦ʻ6ϣN8ȤBcRAV\Z^&SU~%CSWQ@#2
W_AD`EPABIKRDFVS)EVLQK)JKSQXUFYK[M`UKs*$GwU#(QDXBER@CBN%
Rs0~53%eYrd8mt^7Z6]iTF+(EWfJ9zaK-iTV.C\y<pjxsg-b$f4ia>
--------------------------------------------------------
128 bit encrypted signature, crack if you can
|
|
|
|
|
Xmen wrote: Therefore, i thought to copy all the dlls in users' system32(64) directory
Don't do that.
Xmen wrote: mean how to tell my app that read the dll from that directory instead of reading from its own. Any idea ?
you can't. It will check it's own dir first, then it will check the directories such as system32 if it can't be found locally. What's your security concern - that people will replace your dll with their own ? They can always decompile yours, anyhow, so you've lost that battle before you start.
Christian Graus
Driven to the arms of OSX by Vista.
|
|
|
|
|
He could a) strongly name them (detects rogue replacement), and then b) run an obfuscator on them. Most of the commercial obfuscators can merge assemblies, encrypt strings, and create native Windows binaries, so that would solve the decompile problem.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
Christian Graus wrote: Don't do that.
reason ?
Christian Graus wrote: They can always decompile yours, anyhow, so you've lost that battle before you start.
nono, i dont scare of decompile. I know noone can prevent their dlls or exes. All i just want to hide the dlls, my app should look like single exe app. thats it.
TVMU^P[[IGIOQHG^JSH`A#@`RFJ\c^JPL>;"[,*/|+&WLEZGc`AFXc!L
%^]*IRXD#@GKCQ`R\^SF_WcHbORY87֦ʻ6ϣN8ȤBcRAV\Z^&SU~%CSWQ@#2
W_AD`EPABIKRDFVS)EVLQK)JKSQXUFYK[M`UKs*$GwU#(QDXBER@CBN%
Rs0~53%eYrd8mt^7Z6]iTF+(EWfJ9zaK-iTV.C\y<pjxsg-b$f4ia>
--------------------------------------------------------
128 bit encrypted signature, crack if you can
|
|
|
|
|
Xmen wrote: All i just want to hide the dlls, my app should look like single exe app. thats it.
The best way to do that is to merge the assemblies.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
John Simmons / outlaw programmer wrote: merge the assemblies.
hehe how simply you said that, any way ?
TVMU^P[[IGIOQHG^JSH`A#@`RFJ\c^JPL>;"[,*/|+&WLEZGc`AFXc!L
%^]*IRXD#@GKCQ`R\^SF_WcHbORY87֦ʻ6ϣN8ȤBcRAV\Z^&SU~%CSWQ@#2
W_AD`EPABIKRDFVS)EVLQK)JKSQXUFYK[M`UKs*$GwU#(QDXBER@CBN%
Rs0~53%eYrd8mt^7Z6]iTF+(EWfJ9zaK-iTV.C\y<pjxsg-b$f4ia>
--------------------------------------------------------
128 bit encrypted signature, crack if you can
|
|
|
|
|
You can use IlMerge[^] to merge managed assemblies.
|
|
|
|
|
yupp mate, i tried that too but that thing is very typical. After spending hrs on that i had nothing new 
TVMU^P[[IGIOQHG^JSH`A#@`RFJ\c^JPL>;"[,*/|+&WLEZGc`AFXc!L
%^]*IRXD#@GKCQ`R\^SF_WcHbORY87֦ʻ6ϣN8ȤBcRAV\Z^&SU~%CSWQ@#2
W_AD`EPABIKRDFVS)EVLQK)JKSQXUFYK[M`UKs*$GwU#(QDXBER@CBN%
Rs0~53%eYrd8mt^7Z6]iTF+(EWfJ9zaK-iTV.C\y<pjxsg-b$f4ia>
--------------------------------------------------------
128 bit encrypted signature, crack if you can
|
|
|
|
|
Because one feature of .NET is meant to be that you can copy a folder and move it to another machine to redeploy. Also, because those folders get polluted with too much crap and it's better not to contribute. Finally, if some other app has a dll with the same name as yours and they go to the same place, what happens then ? Oh, if you have to release more than one version of the sale dll, putting them in the app folder means you can safely do that.
Christian Graus
Driven to the arms of OSX by Vista.
|
|
|
|
|
yeah i agree with you but dude understand this situation...this is different, no connection with any rule or anything. E.g. a best friend of you that says to you to make an app for him/her and (s)he says also that app must be single exe then what will you do. Wont you develope one ? Will you say him/her that this is poor design ?
TVMU^P[[IGIOQHG^JSH`A#@`RFJ\c^JPL>;"[,*/|+&WLEZGc`AFXc!L
%^]*IRXD#@GKCQ`R\^SF_WcHbORY87֦ʻ6ϣN8ȤBcRAV\Z^&SU~%CSWQ@#2
W_AD`EPABIKRDFVS)EVLQK)JKSQXUFYK[M`UKs*$GwU#(QDXBER@CBN%
Rs0~53%eYrd8mt^7Z6]iTF+(EWfJ9zaK-iTV.C\y<pjxsg-b$f4ia>
--------------------------------------------------------
128 bit encrypted signature, crack if you can
|
|
|
|
|
If you place dlls in other directory, you can use Appdomain.AssemblyResolve event to point your application to the dll it needs. But as everyone can look into your application, they will be able to see the directory where the dlls reside.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
