PowerShell Studio Feature RequestsFeature requests, product enhancement ideas, and other product-specific suggestions.
`Cache` Module / Assembly Binding
Bosparan, Oct. 16, 2017Released:
virtually all of my projects contain a c# library. I've found it to be the most sanitary way to keep function from data definition and there are plenty of other advantages bestowed by it. At this point: Enter PowerShell Studio.
You provide Primal Sense for all modules through building the cache and you provide it for assemblies directly specified to the individual file or when added to the defaults. Given my approach, this is highly problematic, as you lock the files!
Assemblies / Default Assemblies
Want to update the library? Sure, but it requires shutting down PSS, copying the file, then starting PSS again. Since the only practical approach to Primal Sense on a project's scale is to add the file to the default assemblies, this requires me to shut down _all_ instances of PSS. This makes it highly inconvenient to use while developing a new hybrid feature (which incidentally happens to be the moment where having Primal Sense for .NET Types would be most helpful).
When deploying a module for a quick test-run, it automatically rebuilds the cache (something I highly approve of and know how to disable if needed). Now, the cachebuilder is a separate process, but it basically runs over all modules, including the one you just pushed. While this is what you'd expect it to do, it also locks the dll libraries the modules use. So if I start a test, notice an error, fix it and then try to push the update _while the cache builder is not done yet_ it will fail to deploy the library (since it's still locked). This makes quick, iterative tests and automatic cache updates mutually exclusive.
- Have the cachebuiler work with copies of the modules, rather than the originals. Monitor the originals for changes, on change copy changed modules to another path and build the cache again based on the copy. The cache buidler could then run constantly and automatically react to all changes.
- Have the Assemblies for which you directly provide Primal Sense copied to another location and interpret those copies in a separate process that returns the results to the main process. This way you could automatically update this information on library changes (create copy, load in new AppDomain, build cache anew, destroy AppDomain).
I'm aware this would require some serious engineering effort to implement, however it would be a significant upgrade to my development experience, as this affects literally every single module I currently work with.