Doesn't handle wildcard Includes
CADbloke opened this issue · 2 comments
<Compile Include="**\*.cs" Exclude="AssemblyInfo.cs;**\Temp*.cs" />
in the source csproj
will crash the GUI when linking / re-linking.
Here's the crash
I crashed at Recycling. GetFullPath:
C:\Codez\CadBloke\GitHub\CADtest\CADtest-CS\**\*.cs
. Whups. See CodeLinkerLog.txt for details.
System.ArgumentException: Illegal characters in path.
at System.IO.Path.CheckInvalidPathChars(String path, Boolean checkAdditional)
at System.Security.Permissions.FileIOPermission.QuickDemand(FileIOPermissionAccess access, String fullPath, Boolean checkForDuplicates, Boolean needFullPath)
at System.IO.Path.GetFullPath(String path)
at CodeLinker.DestinationProjLinker.LinkCode() in C:\Codez\CadBloke\GitHub\CodeLinker\codelinker\DestinationProjLinker.cs:line 158
Investigate a better way that doesn't need to reparse relative links (including wildcards) by tweaking the relative path of the Source Include
to create the new Include
for the destination project. Concatenating **\*.cs
to the end of a folder paths should still work for Visual Studio / MSBuild but it's not a legal path name, hence the crash.
Test for
- linking a
csproj
that has already been linked - linking a
csproj
into the same directory - linking a
csproj
that has already been linked but now has a different, &/or shallower relative path than its source (that source being the destination of another source). ie. the new relative path for theInclude
is not just an easystring.Replace()
...OR IS IT?
Perhaps any wildcard includes should be regarded as a Keeper
in the initial creation of the Destination project and moved outside the "Link Zone", out of harm's way. before any linking happens. Of course the URL in the Include
would still need to be the right one.
Reason: Wildcard includes are something a user has hand-edited, Visual Studio doesn't do them.
Is that the sound of me shooting myself in the foot?