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?.
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).
"Why did we say we were going to say we were going to change the world tomorrow yesterday? Maybe you can." - Myself
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.
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).
"Why did we say we were going to say we were going to change the world tomorrow yesterday? Maybe you can." - Myself
Launcher runs
if an update is available, prompt for update
if update is chosen, download the new .jars and replace the old ones
dynamically load in the jars, run the main class
Quit procrastinating and make something awesome.
Ducky wrote:Give a man some wood, he'll be warm for the night. Put him on fire and he'll be warm for the rest of his life.
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.