I agree that the creation of dll on the fly is likely to pose a lot of problems. It felt wrong even when I was doing it. Messing up with the filesystem for something that happens at runtime, not under my control looks like a recipe for disaster.
The reason that those dll are required is that I need something to act as a plugin for FARR and forward all call to Fscript2.
I think it's necessary to create DLL on the fly AND to deploy dll automatically, because of the following reasons :
- There might be bugs even in the proxy, and we would end up with the same issue as fscript1 (much less likely than with fscript 1, but still possible )
- Proxies must be loaded AFTER fscript2.dll otherwise they couldn't forward calls because fscript2 doesn't exists. Locating them in a subfolder of fscript2 is a trick that allow to force FARR to detect them and load them after fscript2.
- If we don't copy the dll automatically, we may end up with binary incompatibility between Fscript2 and its proxy. Copying automatically guaranty that we won't have mismatchs.
If we still go the route of creating dll, I could create them in some other place with less security restriction than "program files". There are places were creating file wouldn't be a issue. It would require to have some FARR support to add another directory as a plugin folder and guaranty that it will load after fscript2.
Another solution would be that fscript2 handle all the script interactions internally, but that would require that I mimic all the FARR behavior inside fscript, and it would not be possible to change aliases, regexes, disable individual plugins, etc... It's too much work.
Another solution would be that FARR support the hosting of multiple plugins inside one DLL, but it's a lot of work for mouser, and tests, etc... as it is the core of FARR plugins.