-
-
Notifications
You must be signed in to change notification settings - Fork 165
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
TypeInitializationException on OSX #222
Comments
Thanks for your report. What version of OSX are you testing on? |
Hi @AArnott , we're using High Sierra 10.13.2 |
Also on OSX 10.13.6. Nerdbank.GitVersioning 2.1.84 does not exhibit the problem. |
Oddly, |
@rgmills What about you? Are you using Isn't If |
Yes - that's If you have any pointers to where I might look, I would be happy to try to figure out what has changed between 2.1.84 and 2.2.13 to break Mono |
Thanks, @frankbuckley. I have no idea how to debug mono msbuild on Mac. On Windows I'll sometimes add a Between 2.1.84 and 2.2.13 the primary change was adding support for Ubuntu 18 and other more recent linux distros. It was a lot of trial-and-error changes to try to get everything working at once. It was a delicate balancing act. So if we can get this to work for mono, we'll need to revalidate on all the other platforms we support. I'm building up my prowess at Azure Pipelines build validations that include many different target OSs and versions that should help with that. Yes, whatever you can do to help investigate would be much appreciated. |
@AArnott - I have made a start at figuring it out. My first thought was this was the problem - in that it will return However, changing that did not fix the The only thing I have found so far that 'fixes' (works around) the problem it is to put copies of the libraries back under MSBuildFull. I have confirmed this does not break I have been playing around with a test project that can be used to test with |
Ah, yes that's great that putting those DLLs back solve the problem. I remember I removed them because they didn't appear to be needed any more -- not because they were causing any problem other than making the package bigger. I wonder if we can avoid the extra copy of DLLs by just adjusting the .targets files somehow... but I'm OK to bring them back if that's the only way we know how to go. I appreciate all the validation you've done as well. Regarding the LKG, that was a one-off change of source code where I added a PackageId property to the project and packed it, then pushed that package. I think it was that simple, but as you can tell, it was a while back that I did it. It certainly warrants a refresher now, particular for the sake of the regression testing you mentioned. Let's get your existing fix in first (can you send a PR?) and then I can spin another LKG and then if you can prepare the change to get the tests running on multiple OSs smoke test it on each build system, that would be awesome. |
👏 @frankbuckley highly appreciate you working on this since I just started running into this myself - unable to use vscode on Mac to work on projects at the moment. |
Thanks @frankbuckley and @AArnott . Great surprise to see coming back from vacation! |
Bumps [dotnet-coverage](https://github.com/microsoft/codecoverage) from 17.8.6 to 17.9.1. - [Commits](https://github.com/microsoft/codecoverage/commits) --- updated-dependencies: - dependency-name: dotnet-coverage dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Hello,
We recently updated to 2.2.13 (from 2.1.23) and are encountering an issue on OSX.
Tools:
Below is the error output:
Let me know if there is any additional information I can provide.
The text was updated successfully, but these errors were encountered: