Reduce length of the paths we make for temporary generated files #49059
Conversation
Right now when we open a generated file, we make a temporary file on disk to placate parts of the VS API that need a file on disk. (If we had the ability to have our own URI or moniker that'd be fine, but for now we don't have such an ability.) The original plan was to pack in the necessary information we need into the path so we can figure out what file that represents so we can re-open generated files between runs of VS without requiring actual state. In practice, that didn't work yet (if nothing else, because we're packing in a project ID which is random GUID that isn't persisted across process runs). But the bigger problem is this also runs into MAX_PATH issues, if the generator assembly or type names are fairly long. So for now, let's just generate a GUID for the name and store the extra information in a little lookup table. This, and also just renaming the parent directory we put things in, shaves off a fair number of characters, and also means the name of the generator assembly or type name are no longer something being added into the overall path length. The only "controllable" parts of the path that can vary in length is the file name (which must match the hint name from the compiler), and the user's username. Fixes dotnet#47782, or at least as well as we can.
This seems like this would be a problem for LSIF generation. If we don't have a well known location for the files, how do we find them or refer to them in a sensible fashion? |
|
@CyrusNajmabadi: I'm a bit confused by the question. The IDE doesn't read the source generated files on disk since we may not even have such a feature on. I'm not sure @chsienki whether we've see issues there too, but people may have not used it much in the wild yet. |
|
ghost
added this to the 
Right now when we open a generated file, we make a temporary file on disk to placate parts of the VS API that need a file on disk. (If we had the ability to have our own URI or moniker that'd be fine, but for now we don't have such an ability.) The original plan was to pack in the necessary information we need into the path so we can figure out what file that represents so we can re-open generated files between runs of VS without requiring actual state.
In practice, that didn't work yet (if nothing else, because we're packing in a project ID which is random GUID that isn't persisted across process runs). But the bigger problem is this also runs into MAX_PATH issues, if the generator assembly or type names are fairly long. So for now, let's just generate a GUID for the name and store the extra information in a little lookup table.
This, and also just renaming the parent directory we put things in, shaves off a fair number of characters, and also means the name of the generator assembly or type name are no longer something being added into the overall path length. The only "controllable" parts of the path that can vary in length is the file name (which must match the hint name from the compiler), and the user's username.
Fixes #47782, or at least as well as we can.