Odd DLL version numbering preventing debugging

[Infarinato]

I do apologize in advance for the very trivial question, but need to debug a pesky Sitecore/OWIN/SAML single logout issue, where the authentication user principal is getting dropped at the request stage —I already know it’s neither a Microsoft.Owin nor a Sustainsys.Saml2 issue, as virtually the same configuration is used in a sample MVC app, where everything works as expected, but I do need to look inside the Microsoft.Owin.Security.AuthenticationResponseGrant method to see what’s actually happening (verbose logging doesn’t really help me).

So, I have downloaded the latest 4.2.2 release hoping to recompile the sources in non-optimized mode. Recompiling works fine, but, whereas the generated Product Version is correctly 4.2.2, the File Version gets set to an odd (for me, at least!) 42.42.42.42424, so of course this won’t get recognized as the right version (and manually changing the version would of course mess up the strong name signature).

Does anyone know how I can get the solution to generate the correct file version number? Otherwise, if the non-optimized versions of the Microsoft.Owin DLLs are already available somewhere, I’d be grateful if someone could let me know where I can find them. 😊

Many thanks.

[Tratcher]

Local builds always use that file version to avoid conflicts with official builds. I think you can do something like build.cmd -c DEBUG -ci for a more official looking build.

AspNetKatana/eng/common/build.ps1

Line 41 in 43996b4

Write-Host " -configuration <value> Build configuration: 'Debug' or 'Release' (short: -c)"

[Infarinato]

Cheers for the pointer, @Tratcher. Build (after a clean 😉) was successful (no warnings or errors), but, alas, still funky file version and no digital signature… ☹️

[Tratcher]

@wtgodbe any hints?

[wtgodbe]

I think you need to pass in an OfficialBuildId in order for the build system to think this is a real build, which will cause it to set a "real" AssemblyVersion. Something like build.cmd -c DEBUG -ci /p:OfficialBuildId=20240329.4 should do it (doesn't have to be that exact OfficialBuildId, I think it just has to match the format YYYYMMDD.X)

[Infarinato]

Cheers, both. 😊 Getting closer, @wtgodbe: now I’m getting a similar-looking file version to the original one, and a product version of the from 4.2.2+horrendous_GUID, again mimicking the original. Yet, there is no digital signature, and IIS gives me the not unexpected

Could not load file or assembly 'Microsoft.Owin' or one of its dependencies. Strong name signature could not be verified.  The assembly may have been tampered with, or it was delay signed but not fully signed with the correct private key. (Exception from HRESULT: 0x80131045)

Now, I guess there is really no [safe] workaround for this unless… I’m Microsoft. 😅

Is it really my only option to replace the whole Microsoft.Owin stack in my solution(s) with the debug versions and change the publicKeyToken in my Web.config accordingly? 🤔

What do you guys normally do when you test new versions in existing solutions?

[wtgodbe]

passing /p:DotNetSignType=test might get you what you need - though I haven't actually worked with the code in this repo personally, I'm just going off common patterns from our infra.

[CZEMacLeod]

In EF6 and aspnet/AspNetWebStack there is a custom target EnableSkipStrongNames (and DisableSkipStrongNames) which will make the local machine ignore strong names for a specific assembly/strongname key and allow you to test locally.

I don't know if that is implemented in this repo, but it would be useful, and you could check there on how it is implemented.
HTH.

[Infarinato]

Thanks again, William, for your patience… I did use the /p:DotNetSignType=test option, as you suggested, and replaced all the existing Microsoft.Owin DLLs in my solution with the debug versions (and even removed the relevant publicKeyToken attributes from my Web.config), but am getting the same error message about IIS not being able to verify the strong name signature… I guess working around this might prove nearly impossible without in-depth knowledge of signature verification, which I certainly do not have.

And thank you, Cynthia, for your suggestion: I was vaguely aware about ways of removing strong name validation (for some assemblies only or globally), but am no expert and am always a bit worried of doing any of that on a corporate machine… 😅