Elysian Shadows

Hey guys, just a quick question, how bad would it be if I make my application nearly completely dependent on .Net reflection assembly invokes to invoke, create or modify methods, properties etc... in a .Net assembly?.

I was thinking of something like Btw, the code is not accurate to .Net functions so LoadAssembly would be the System.Reflection.Assembly. ...

It would just make it slow(er)..

Can you explain your reasoning for this?

Sure, the reason I want to do this is because I have an updater.exe which basically updates an application as well as having a neat little mini file system. I want to use reflection from the main application to use this file system feature but have the executable in a seperate directory or even have the updater application access the main applications core libraries.
I would plan to use a "FileSystemWrapper" class which acts as an interface for the main application to use

In terms of safety (as in file corruption) I would say this is risky, of course I have little to no experience with .Net but this concept just seems
like something along the line might get corrupted.

In terms of efficiency I would not know weather File IO (re-writing/replacing the files that need to be updated) or messing with .Net Assembly is faster.

The tie-breaker I would use here is the question of "do you want your application to be cross-platform?".

To answer your question however, on a scale of -10 to 10 (10 being excellent practice) I would classify this as maybe a 1 or a 2 (Eh' not bad but not good).

The mini file system in update.exe is essentially storing all the update data (update installation) files in 1 so essentially (sorry I did'nt mention this..), the system won't get clogged up with files and it's slightly secure (basic encryption).

I don't really see how corruption can occur since .Net reflection is just loading the C# .Net compiled assemblies within update.exe and does not require any writes to that actual .exe file.

Sorry my small brain has become confused . I just want to make sure I have this right, is this what you are doing?
EDIT:
Oops forgot to draw an arrow.

Yes. But instead of using .net to manipulate the app, it's more like, using .net to manipulate the data and app.

Edit: Sorry it's late when I posted that. Yes, you pretty much summed it up

Is there a reason you cannot just update the entire assembly (keeping the interface the same) when you do an update rather than relying on reflection. Maybe it's because we don't have all the details but I can't see why you would use reflection.

Well the main application and updater has to work both ways, I mean, the main application accesses update classes and the updater accesses application classes.

There is two reasons I want to use reflection, one is that I won't need to depend on that assembly as a reference and 2, I would rather have the updater in a seperate directory.

Personally I would just re-write the necessary files, however I don't see a reason why not to other than something getting corrupted (that tends to happen with M$ products in my experience).

It seems that you're trying to do something similar to minecraft's update scheme, which basically does this:

Lol im getting confused now...

This is how the system works right now

update.exe
FileSystem class (these functions are'nt actually present but it sums it up...)
byte[] Load(string reference); //outputs the byte data for the file
string Create(Stream stream); //outputs the new file reference

The file system itself actually has no file names, instead, it's comprised of "references" to the files data. The "reference" string for Load is basically a DIRECT reference to the files data, but the file data has some information behind it which is date created, date accessed and other arguments (the whole file info part is 28bytes) (fixed)).
I have tested the file system and uploaded a 700mb movie, then downloaded the data back off again, watched the movie and NO errors in movie quality/sound or anything else occured. Btw, there was about 40 files making up 6gb of data, but that was without encryption (I haven't coded that bit yet)

An example of a reference string would be "000000000000001C000000001", the first 16 characters is the hex code for a (long)start location and the other 16 characters is the (long)length of how big that file is. All of this removes the chances of corruption since, once the data is written, the length of that file can no longer be any bigger, but the contents may be changed. But now, I can hear you saying, well thats corruption since I can specify a length outside the files data to access another files info&data. Well if thats the case, yes, it would lead to major corruptions, but that is ONLY if someone has physically modified that file themselves because the application would keep a database of these references to tell update.exe which one is which.

Now, thats the CORE of update.exe and I want to keep this functionality in the actual app to either use for caching stuff etc...

This part has not been coded yet
=======
Update.exe would (in the background) look for updates, if an update exists, it downloads it to the file system and keeps it their until the client tells the update.exe to apply that update to the application. At which point, update.exe replaces all necassary files in order to accomplish the update.

Sounds good to me!