Calendar API 1.45 v 1.46

[FISHMANPET]

I'm not really sure what can be done about this, but... in 51068a3f403e91829034ab3f0d9d0209f4f58342 you added this: https://github.com/SCRT-HQ/PSGSuite/blob/51068a3f403e91829034ab3f0d9d0209f4f58342/Tests/1.%20Module%20Tests/PSGSuite.Help.Tests.ps1#L16-L18 This part of the tests explicitly loads all the DLLs. This spit out an error in the pester test:

ErrorRecord            : Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information.
ParameterizedSuiteName :
Describe               : Public Function Help tests
Parameters             :
Passed                 : False
Show                   : All
FailureMessage         : Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information.
Time                   : 00:00:00
Name                   : Error occurred in Describe block
Result                 : Failed
Context                : 
StackTrace             : At C:\Users\bajurny\Documents\GitHub\PSGSuite\Tests\1. Module Tests\PSGSuite.Help.Tests.ps1:17 char:9

I looped through them in my terminal to look at the Loader Exceptions property and it was this repeated 72 times:

Could not load file or assembly 'Google.Apis, Version=1.45.0.0, Culture=neutral, PublicKeyToken=4b01fa6e34db77ab' or one of its dependencies. The system cannot find the file specified.

Well that's weird, Google.Apis is there, but turns out it's version 1.46.00.

Wrote another loop that told me what was being imported before it imported so I could find the failures, and discovered it was the Google Calendar API. Looking at all the file versions Calendar is 1.45 while everything else is 1.46. According to this issue there may be a lag between when the core API library is released and when support libraries are released. But also it looks like their discovery resource for the calendar library has been removed from the repo (see my comment on that issue).

So, not sure what to do here. If it's normal that sometimes things are out of sync, maybe just be careful when things are deployed? Otherwise if there is a bug in their auto-generation of libraries I guess wait for it to be resolved and calendar 1.46 released. While this error showed up because of that added code in the test file, I suspect that absent that, if you "released" a version of PSGsuite while the .net libraries are out of date there would be some issues.

[scrthq]

I've noticed that with other DLLs, seems like they don't all have a similar release cadence :-( This is also why Tasks was pulled out a bit ago.

I'm wondering if we should just add a shell C# project with the assemblies listed then run dotnet build to pull down assemblies that would work together? Not 100% sure if that would work as expected though.

The force load was added because the Help tests actually were failing due to Type Not Found, even though the module is force imported right before.

[FISHMANPET]

Not sure even that would do it... I was thinking about how get dependencies in pure Powershell, and looking at the dependencies for the Calendar 1.45 package, it says it requires the core API and Api.Auth >=1.45. 1.46 would meet that criteria so it would grab 1.46. I think even doing dotnet build would fail to grab the needed 1.45 libraries because the dependencies stated on nuget.org and the actual library dependencies don't match.

So I guess another issue here is that the dependencies they're stating aren't even correct, and I'm not sure there's any way around that programmatically.

[FISHMANPET]

Not being able to leave well enough alone, and based on this comment from my issue on the Google Repo:

Note that on .NET Framework (as opposed to Core) you'll need assembly binding redirects to be set up appropriately

The issue appears to not be with the dependencies of the assemblies, but how they're loaded. Assembly binding redirects are... weird.

Also, Tasks library seems to be being updated again, so those could be pulled back in. Guess we need to keep an eye on library versions and complain to google when they get off, or figure out binding redirects.

[scrthq]

We could potentially add a custom assembly resolver to AppDomain. Doesn't seem to be too difficult, would need to test though

[FISHMANPET]

And looks like Calendar 1.46 is now published

[scrthq]

alrighty @FISHMANPET - I've got the custom assembly resolver working well, just forced Calendar 1.42 in with the rest of the 1.46 assemblies and everything is still working well 😃 Should have this permanent fix in place in next release

[FISHMANPET]

So the specific code that caused this specific issue was in the Help Tests where it loads all the DLLs into the current scope so that Help tests wouldn't fail as soon as they encountered a type that wasn't loaded.

I saw this failure while debugging the auto-generation functions, there was a function generated with an invalid object type, and the tests would fail. However right now, if I remove the lines that explicitly load the DLLs in the scope of the test, the tests still pass, which tells me they still have access to all those types. So I suspect your assembly resolver loads the DLLs in such a way that they're available when running those help tests.

I'll do a little more playing around (forcing some old versions of libraries like you did) and make sure tests still pass, and then I think we can call this good (once it actually gets released 😆)

[FISHMANPET]

And it doesn't work on PS 5 😞 Not sure if it's worth putting much effort into, since the case where the libraries were out of sync was a bug on Google's part, and if they get out of sync we can raise an issue with Google about it in the repo I linked above.