-
-
Notifications
You must be signed in to change notification settings - Fork 27
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Major changing for Guid (UUID) core processing. Moving up to Fnv-1a-128 based algorithms #51
Comments
Part of Issue #51 MvsSlnFeatureHuid via Huid 1.0.0 https://github.com/3F/Huid/releases/tag/1.0
Starting with 187f0e9, you can define the following:
Note:
<ProjectReference Include="...MvsSln.csproj">
...
<AdditionalProperties>MvsSlnFeatureHuid=true</AdditionalProperties> because we're using a common.props |
MvsSlnFeatureHuid=true 3F/MvsSln#51 (comment)
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.
The text was updated successfully, but these errors were encountered: