Here, I was saying about Huid (-> Fnv-1a-128 (-> LX4Cnh)) which provides related fastest generating UUID in a .NET System.Guid compatible manner.
Today's MvsSln relies on MD5 (or SHA-1, edition for DllExport) when generating and comparing something from strings using Guid.
For example, XProject.PId and related Guid-like hashing
|
PId = CalculatePId(prj); |
|
} |
|
|
|
protected Guid CalculatePId(Project prj) |
|
{ |
|
if(Project == null) { |
|
return Guid.Empty; |
|
} |
|
|
|
return ( |
|
FindGuid(prj) |
|
+ ProjectItem.projectConfig |
|
+ ProjectItem.solutionConfig |
|
) |
|
.Guid(); |
This, of course, should not affect any well known Guids for VS/msbuild support. Only parts where must be generating a new one from input string. However, this invalidates the previously generated values which may require a complete re-evaluation in some cases.
Please feedback if this upgrading may cause problems and cannot be adapted in some used infrastructure etc.
Here, I was saying about Huid (-> Fnv-1a-128 (-> LX4Cnh)) which provides related fastest generating UUID in a .NET System.Guid compatible manner.
Today's MvsSln relies on MD5 (or SHA-1, edition for DllExport) when generating and comparing something from strings using Guid.
For example, XProject.PId and related Guid-like hashing
MvsSln/MvsSln/Core/XProject.cs
Lines 752 to 766 in 2cc2dd8
This, of course, should not affect any well known Guids for VS/msbuild support. Only parts where must be generating a new one from input string. However, this invalidates the previously generated values which may require a complete re-evaluation in some cases.
Please feedback if this upgrading may cause problems and cannot be adapted in some used infrastructure etc.