The more I work with videojs-ima, the more I am convinced it is not the solution for what we are doing. Any time I try to figure out how to do a thing on my current project, the answer is usually "don't". Then I need to hammer the app til "don't" becomes "does sorta"

As "that guy who has used graphql a bit" at work, I feel I see this when people are sent my way when they run into trouble making it do what they need. I still haven't found a good way to basically say "well there's your problem: You shouldn't be using graphql for this"

@ltlian I feel that is the problem with software in general. "Why can't I do this with X?" "Cuz that's not what X is for!" Or worse, "Hey if you use X it will solve your problem." "That's not how we use X." "That's LITERALLY what X is for."

That second case is what happened when I was trying to solve a GAC problem in a system that blatantly abused the GAC.

@projektaquarius
The first rule of GAC is you don't use the GAC.

@SortOfTested on my old project we put everything in the GAC for some reason. We started getting rid our GAC stuff but I left before completion. But then we upgraded a DLL we were dependent on, but we would break a component we interacted with if we installed first, because they used an older version of the DLL. I told them to put it in the GAC because that's what it's for, but nooooo. Let's not use the GAC to resolve DLL hell as Microsoft intended. Let's just use it as a convenient dumping ground for all the DLLs rather than fix our pathing.

@projektaquarius
That seems such a past-tense, operating system specific solution to a non-problem I don't even know where to begin.

It's just not that hard to use msbuild to produce a deployment package.

@SortOfTested if only if only. They were using old ass install shield. And for some reason they wouldn't let software engineering control the generation of the installer. Also their were dumb rules we were required to follow because we were technically a plugin for an app. Also it was DoD, which has other complications.