|
| 1 | +--- |
| 2 | +layout: post |
| 3 | +title: "A new filesystem" |
| 4 | +tagline: "Playing better with .NET solutions." |
| 5 | +category: Releases |
| 6 | +tags: [changes] |
| 7 | +--- |
| 8 | +{% include JB/setup %} |
| 9 | + |
| 10 | +With script version 0.13 we decided to make some changes to help scriptcs run more smoothly together with existing .NET solutions. A problem which existed until now was the occasional inability to run scriptcs from within the folder of a regular .NET solution due to problematic assemblies in `packages` or `bin` folders. These would be assemblies which were not installed in order to be used from scriptcs, but rather from the .NET solution, and cause errors or warnings when running scriptcs. In particular, developers and users of build systems based on scriptcs, e.g. [PVC](http://pvcbuild.com/) and [Bau](https://github.com/bau-build/bau), were often tripped up by this. |
| 11 | + |
| 12 | +The problem occured because, until now, the file system conventions used by regular .NET and scriptcs overlapped. They both used `packages.config`, `packages/` and `nuget.config` for NuGet package management and scriptcs searched `bin/` for binaries, a folder often used for other purposes in a .NET solution. |
| 13 | + |
| 14 | +Starting with version 0.13, we've changed our conventions to isolate our file system artifacts from interference with a regular .NET solution. |
| 15 | + |
| 16 | +<pre> |
| 17 | +.cache -> .scriptcs_cache |
| 18 | +bin/ -> scriptcs_bin/ |
| 19 | +packages/ -> scriptcs_packages/ |
| 20 | +nuget.config -> scriptcs_nuget.config |
| 21 | +packages.config -> scriptcs_packages.config |
| 22 | +</pre> |
| 23 | + |
| 24 | +### Automatic migration |
| 25 | + |
| 26 | +When you run scriptcs 0.13, it will detect 'legacy' file system artifacts (those shared with regular .NET) and automatically migrate them. To ensure anything outside scriptcs keeps functioning (e.g. an existing .NET solution), the existing artifacts are left in place, and copies are made instead. The only artifact which is renamed is `.cache` (to `.scriptcs_cache`) since this was never shared with regular .NET, but has still had it's named change for consistency. |
| 27 | + |
| 28 | +E.g. if your folder looked like this *before* running scriptcs 0.13 (you may not have all of these artifacts): |
| 29 | + |
| 30 | +<img src="/images/2015-02-02-before.png" /> |
| 31 | + |
| 32 | +you will see this output when running scriptcs 0.13: |
| 33 | + |
| 34 | +<img src="/images/2015-02-02-during.png" /> |
| 35 | + |
| 36 | +and you your folder will end up looking like this: |
| 37 | + |
| 38 | +<img src="/images/2015-02-02-after.png" /> |
| 39 | + |
| 40 | +If you don't need the original artifacts, feel free to delete them. It would be very difficult to automatically detect, with certainty, whether or not they're required so we thought we'd leave it to you to decide. |
| 41 | + |
| 42 | +### Performance |
| 43 | + |
| 44 | +Another nice effect of this changed is a potential increase in performance. When scriptcs starts up, it scans `bin/` and `packages/` for modules and script packs. Previously, a large .NET solution may have many assemblies in these folders, not required for script execution, and this would result in a performance hit. With the new file system conventions, only those assemblies needed for script execution are scanned and that should speed things up in many cases. |
| 45 | + |
| 46 | +### Hosting |
| 47 | + |
| 48 | +If you are hosting scriptcs in your own application and you want to perform automatic migration, you will need to call `scriptServices.FileSystemMigrator.Migrate()` at an appropriate place in your application. |
0 commit comments