v2 crashes on run with missing dependency JetBrains.Annotations about terminal.gui HOT 9 OPEN

Multiple simple ways to handle that from our end. Most ideal is probably a little bit of a couple of them.

Just got home, but I'll take a look at it once I'm all settled.

from terminal.gui.

Finally got in. Sheesh. Ok, taking a look.

@tznind

Was that the actual version it threw at you, verbatim, or was that just silliness?

from terminal.gui.

Nevermind on that. Seems that's the actual version in the assembly. 😆

Red Herring anyway.

As with any analysis package, dev dependencies like that are dev-time only for the consumer and don't become part of their application.

All that needs to happen is having the dependency listed in the nuspec, which is just minor project file modification, since the nuspec is auto-generated from that.

I see a few minor issues with the project file aside from that, some of which are just legacy stuff or redundant, and a couple places we can make the builds a bit better/cleaner.

There's one element in the Terminal.Gui.csproj that I'm pretty sure can go but which I wanted to ask you about first, @tig :

What's that <GitRepositoryRemoteName>upstream</GitRepositoryRemoteName> element in the nuget packaging PropertyGroup at the bottom all about? I don't see anything in the build that would require that and all it really does anyway is makes local builds throw warnings that are just noise.

If it is needed by something, for some reason, there are a couple of available options to handle it cleanly. But, if it's not needed, I'll just take it out. Naming git remotes isn't a particularly common step of build pipelines, since it's only really relevant when you have more than one remote defined.

If there's a desire for the github workflow runners to be able to target multiple different remotes for test builds or whatever, that's something better handled in the workflow itself, through stuff like:

• An environment/deployment on github (which is mostly just a group of variables passed to jobs as a set;
• Inputs on workflows, such as:
  • workflow_dispatch, which can have manual inputs specified, with fallback defaults.
  • workflow_run, workflow_call, etc., which are triggered by invocation of or called from other workflows and take inputs from them.

I actually prefer to do a little of all of the above, since they're not remotely exclusive approaches and complement each other quite nicely.¹

In fact, there's a lot of that sort of thing in the various workflows I'm putting together, at least one of which I'm going to be publishing on the github actions "marketplace" for general public use, soon, once I finish polishing it up.²

from terminal.gui.

......

Visual Studio really frustrates me sometimes....

I wasted so much time today fighting it, because it was randomly refusing to load random projects in random solutions. And just recently? Out of nowhere, it worked perfectly for like 20 minutes. Then it went back to being weird again... While I was reviewing an internal PR, so not even changing things!

le sigh 😞

from terminal.gui.

GitRepositoryRemoteName is related to SourceLink.

I think I put it in to try to fix the stupid build warnings. Go ahead and take it out for now.

from terminal.gui.

Visual Studio really frustrates me sometimes....

I wasted so much time today fighting it, because it was randomly refusing to load random projects in random solutions. And just recently? Out of nowhere, it worked perfectly for like 20 minutes. Then it went back to being weird again... While I was reviewing an internal PR, so not even changing things!

This actually happens to me often. Sometimes I try to pull from upstream but I only have origin available and all other remotes are disabled. I am forced to close VS2022 and open it again for it to work, sometimes more than once. When this happens I try to do this operation with VSCode and the same strange behavior doesn't happen. I think that VS2022 is unable to unblock some processes that are preventing solutions and projects from initializing, as well as blocking git in some situations.

from terminal.gui.

GitRepositoryRemoteName is related to SourceLink.

I think I put it in to try to fix the stupid build warnings. Go ahead and take it out for now.

Currently (at least since .net 7), all you typically have to do is Have the package reference and the <EnableSourceLink>true</EnableSourceLink> element, which we have both of.

But, rather than taking out the GitRepositoryRemoteName element, I had a better thought that I've already done in my working copy: Just make the nuget-related stuff conditional and only active when told to be.

I did that and created a configuration for CI builds that does a few other things local builds don't need to do or that can make local builds harder to debug. I could have made it just do it automatically based on finding the GITHUB_WORKSPACE environment variable or something, but a configuration is easier, clearer, and also allows you to run the CI config locally, if you want/need to.

While doing that, I collected all of the stuff related to nuget down in the same part of the Terminal.Gui.csproj file, so it's all nice and clear.

from terminal.gui.

Visual Studio really frustrates me sometimes....
I wasted so much time today fighting it, because it was randomly refusing to load random projects in random solutions. And just recently? Out of nowhere, it worked perfectly for like 20 minutes. Then it went back to being weird again... While I was reviewing an internal PR, so not even changing things!

This actually happens to me often. Sometimes I try to pull from upstream but I only have origin available and all other remotes are disabled. I am forced to close VS2022 and open it again for it to work, sometimes more than once. When this happens I try to do this operation with VSCode and the same strange behavior doesn't happen. I think that VS2022 is unable to unblock some processes that are preventing solutions and projects from initializing, as well as blocking git in some situations.

Haha yep.

And I even deleted caches at every level I am aware of.

It's a wonderful and powerful piece of software. But man, when it wants to throw a tantrum, it goes all out.

from terminal.gui.

And yep, I do the same as you with Code @BDisp. It's usually my backup environment, since it's pretty much the best text editor on my windows partition. 😅 It's also pretty great for other languages, too, so it's usually running anyway.

But MAN I sure do miss all the goodies I've got just the way I like them in VS, when I can't use it.

from terminal.gui.