Microsoft.CSharp.CSharpCodeProvider

F

FarligOpptreden

Executive Member
Joined
Mar 5, 2007
Messages
5,396
Reaction score
31
Location
Gauteng
...is the BEST FRIGGIN THING TO HAPPEN TO ME SINCE SLICED BREAD!!!

To expand a bit: I need to create a proprietary secure document format that leaves no traces of the data on the client. In other words, I can't have a PDF or similar file just archived into a ZIP / RAR file with a password attached to it, because the extracted document would be shoved into a temp folder somewhere. That shouldn't happen. The assembly listed in the title just made my day - dynamically generated and compiled executable files FTW! :D
 
what is in that document ? that should not leave traces :D
 
The nice thing about this solution, is that it WILL be encrypted (and secured by a user-specified password). You won't need to install any odd plugins either, like the Striata plugin required for Multhchoice / Absa / Vodacom statements.

Again, there shouldn't be any form of client footprint, except for the executable file. We discussed to problem at considerable length and decided upon a dynamically generated and compiled executable file. The sample I did compiles in less than a second and works bootifully! :D
 
FarligOpptreden said:
The nice thing about this solution, is that it WILL be encrypted (and secured by a user-specified password). You won't need to install any odd plugins either, like the Striata plugin required for Multhchoice / Absa / Vodacom statements.

Again, there shouldn't be any form of client footprint, except for the executable file. We discussed to problem at considerable length and decided upon a dynamically generated and compiled executable file. The sample I did compiles in less than a second and works bootifully! :D
Click to expand...

Only if you have .net framework though?
 
This is good stuff. What do I call it for the sticky contents? Automated Code Generation/Automated Assembly Generation?
 
Dynamically Complied Code? :p

EDIT 1: dequadin, have you tried it out yet? It really is incredibly awesome and doesn't seem to be widely used. It's a real gem among the .NET assemblies!
EDIT 2: I posted a code snippet to get you rolling in the thread yesterday. I presume you saw it...
 
Last edited:
AcidRaZor said:
Only if you have .net framework though?
Click to expand...

Most people running Windows have the .NET Framework already installed though... And this is being built in .NET 2.0, so even XP users (which is the majority of our market) can take advantage of this.
 
FarligOpptreden said:
Dynamically Complied Code? :p

EDIT: dequadin, have you tried it out yet? It really is incredibly awesome and doesn't seem to be widely used. It's a real gem among the .NET assemblies!
Click to expand...

Nope. I knew it existed but haven't got around to implementing it anywhere. There is the odd question here and there on StackOverflow but not much. I stand corrected but one of the issues is that if you dynamically load one of these assemblies into memory there is no way to free it?

It is on my todo list however. At some point I need to add some scripting into one of our apps. So one of the ideas was to have an interface that the script implements and use dotNetFireball to do all the scripting in. Then dynamically create a dll from the script and then use Reflection to execute it via a plugin architecture.

This is a nice to have rather than must have feature so it's not priority for a while...
 
dequadin said:
Nope. I knew it existed but haven't got around to implementing it anywhere.
Click to expand...
As did I, seeing as Redgate SQL Packager compiles a database "upgrade" script to an executable as well. I really only found use for it now that we need to create this proprietary secure document format.

dequadin said:
I stand corrected but one of the issues is that if you dynamically load one of these assemblies into memory there is no way to free it?
Click to expand...
I'll investigate it a bit as I implement it in our solution...

dequadin said:
At some point I need to add some scripting into one of our apps. So one of the ideas was to have an interface that the script implements and use dotNetFireball to do all the scripting in. Then dynamically create a dll from the script and then use Reflection to execute it via a plugin architecture.
Click to expand...
Well, you don't even need to compile it to a DLL. You can even store it as a text file and execute with reflection on runtime. But I suppose a DLL looks more professional and prevents hacks to some degree... :p

dequadin said:
This is a nice to have rather than must have feature so it's not priority for a while...
Click to expand...
Ah well, but I still recommend you play with it a bit - it really seems powerful. The idea of building a UI to specify some logic and saving it as a piece of C# code to be compiled at runtime and then executed just seems awesome. It opens up lots of possibilities to execute custom code in i.e. a workflow environment. Mind you, that's what K2 does already... :o
 
Ye, but the reason why they require a 3rd party plug-in to install before reading the secure document is because the plug-in is dependent on the OS you have, so you don't segregate those with Mac or Linux.

I guess this is useful if you know for 100% certainty that all of your user base will always be using Windows, but I'm going to sit back, relax with a beer, and check out how you handle the support calls for people fwd'ing the secure document to someone who's not able to open it up due to the restriction...
 
AcidRaZor said:
Ye, but the reason why they require a 3rd party plug-in to install before reading the secure document is because the plug-in is dependent on the OS you have, so you don't segregate those with Mac or Linux.

I guess this is useful if you know for 100% certainty that all of your user base will always be using Windows, but I'm going to sit back, relax with a beer, and check out how you handle the support calls for people fwd'ing the secure document to someone who's not able to open it up due to the restriction...
Click to expand...

Again, our target market is Windows users. I can guarantee you with 100% certainty. ;)
 
FarligOpptreden said:
Again, our target market is Windows users. I can guarantee you with 100% certainty. ;)
Click to expand...

:D Please keep us up to date

Remember... the universe just tends to create a little bit better idiots than you can imagine...

And I have first hand experience...
 
I will keep you up to date - I first have another project to finish off before moving on to this one though. Should be done by the end of November!
 
You must log in or register to reply here.
Back
Top
Sign up to the MyBroadband newsletter
X