Tim Van Holder

It's reproducible for me with `dotnet new console` and then changing Program.cs to have `Console.WriteLine("Hello, World! - {0} {1} {2}", MathF.E, MathF.PI, MathF.Tau);` using the current .NET 6 SDK. If...

Of course, a document could be unused at write time because Cecil was used to remove some code and/or sequence points. In that case, those should probably be discarded. But...

I figure accepting anything that Roslyn (i.e `System.Reflection.Metadata`) does not is not necessary. Such a PDB will already prevent debugging in Visual Studio (which I suppose could be the point...

I suppose the difference could be: - ReadAssembly used without any indication of intent (the default): current behaviour, for backward compatibility - ReadAssembly indicating only intent to read the assembly:...

As mentioned above, currently you cannot assume files will be closed until the assembly is disposed. If the removal still fails if it's after a `using` block for the loaded...

Note that while this issue prevents debugging in Visual Studio (because the entire PDB reading aborts), Rider is less affected (it seems to just silently discard the "bad" sequence points).

Looks like the problem is not so much the hidden sequence points - the sequence point records are emitted correctly. However, the problem is that `SignatureWriter.WriteSequencePoints` assumes that `MethodDebugInformation.SequencePoints` is...

Is there no chicken/egg issue with trying to have the behaviour of the resolver depend on `[TargetFramework]`? For one thing, I would expect it would need to resolve `TargetFrameworkAttribute` before...

I suppose I'm surprised it becomes stable after the first. I could understand each `Write` generating a new MVID (in fact, arguably it should, just like recompiling does even though...

Given that second file has a high(ish) value at the start makes me wonder if there's a static or instance field somewhere that does not get reset.