Doesn't handle wildcard Includes

[Ewen Wallace]

<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 the Include is not just an easy string.Replace()...OR IS IT?

[Ewen Wallace]

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?

[Ewen Wallace]

fe64858 fixes this