Should MultiVirtualDirectory really throw a NotImplementedException?

This code here throws: Should

But seems to assume that this.First() works. GetEnumerator seems to be delegateable to dirs at ?

IMO it’s not valid to try an enumerate all Multi VFS files, you could go to the root directory and enumerate that VFS instead. What usecase do you have for wanting to enumerate Multi VFS files?

I’m trying to get the .RealPath to associate a cache dependency to it, and it fails on the enumeration:

                HttpContext.Current.Cache.Insert(cacheKey, value, new CacheDependency(virtualDirectory.RealPath), DateTime.Now.AddHours(1), Cache.NoSlidingExpiration, CacheItemPriority.High, null);

We use this to cache some parsed content from a file that we take from the VFS and we know lives on the file storage…

That’s going to vary based on what VFS is ordered first. You probably want the RealPath of a specific provider, e.g:


Or if you want the RealPath of the first provider:


FYI I’ve implemented GetEnumerator() in this commit. This change is now available from v6.3.1+ that’s now available on MyGet.

I havent’ been able to test it, as we’re already on a previous 6.3.1, and I want to avoid having different 6.3.1 packages around the pipeline and environments.

I don’t suppose it’s possible to publish the pre-releases with a version that allows us to distinguish between builds? That way we could specify “I want build XYZ that fixes this particular bug” instead of depending on clearing caches and when a package is cached.

No, the MyGet packages are transient if we bump to v6.3.3 then it breaks everyone on v6.3.1 which no longer exists. The pre-release version stays constant until release as per documented versioning scheme.

The typical solution is for CI environments to not cache packages between builds.