* Support batch PDB generation.
* Use `FileMode.Create` for output PDB files to ensure existing files are fully overwritten/truncated.
* Localize the string `Generating portable PDB...`.
* Refine `GeneratePdbForAssemblies` implementation.
* Replace direct calls to `explorer.exe` with the Shell API to prevent spawning an `explorer.exe` process that doesn't exit automatically on every call.
* Batch calls to `ShellHelper.OpenFolderAndSelectItems` instead of looping `OpenFolderAndSelectItem`.
* Localize the string `Open Explorer`.
* Fix `OpenCmdHere` malfunction when ILSpy is running from a different drive than the OS.
* Refine `GeneratePdbForAssemblies` implementation.
* Replace WinForms `FolderBrowserDialog` with WPF `OpenFolderDialog`.
* Add license header
* Exclude duplicate entries entered by the user within `OpenFolderAndSelectItems`.
* Explicitly declare that `ShellHelper.cs` is a module that allows Pinvoke.
* Use `FileMode.Create` for output PDB files to ensure existing files are fully overwritten/truncated.
* Show original filenames when generating PDBs to improve UX during batch processing.
This commit adds a new parameter to PortablePdbWriter.WritePdb that
allows the caller to provide an implementation of IProgress to receive
status updates on the pdb generation process. Currently, the progress
reports include the number of files generated so far and the total
number of files.
This commit adds a new parameter to PortablePdbWriter.WritePdb that
allows the caller to specify the exact Guid and timestamp that should be
used in the generated PDB. This will be useful for several scenarios
that are interesting for the Visual Studio debugger's integration:
1. Generating a PDB for an assembly that was built without debug info.
The PDB writer currently fails in this case, since the input assembly
has no debug directory from which to extract the relevant info. The
debugger can provide values that will allow us to load the generated
PDB.
2. Generating a PDB for an assembly that has multiple debug directories.
The PDB writer currently uses the first debug directory it finds, but
this isn't necessarily the correct one. The debugger can provide the
correct values.
or implicit sequence point without creating overlapping sequence points.
If such a location cannot be found do, nothing. Fill in the
gaps with hidden sequence points.
Also emit a sequence point for
the prolog to account for seqeunce point there emitted by the C#
compiler. Without this, the debugger can stop there on a step in
using the original pdb, then decompile resulting in a no-code at this
location failure.
While support for multi-module assemblies isn't fully working yet; it is clear at this point that we want
to treat each module in a multi-module assembly separately for the purposes of the type system.