Closed mwpowellhtx closed 6 years ago
Should also clarify, as I've done in other places, I am spooling up the project from a VS2015
project, Framework 4.6.2
(or greater) target, to begin with.
Trying to walk the version back to a dependency that is at least compatible with Framework 4.6.2, and the first attempt 0.4.37
fails because:
Severity Code Description Project File Line Suppression State
Error Unable to find a version of 'CodeGeneration.Roslyn.Attributes' that is compatible with 'CodeGeneration.Roslyn 0.4.37 constraint: CodeGeneration.Roslyn.Attributes (>= 1.0.0)'. 0
Your dependencies are broken in the NuGet package.
The most recent one that seems to work, or at least NuGet is satisfied resolving the dependencies, is 0.4.11
.
That being said, what is the migration path moving forward? i.e. supporting Framewotk 4.6.2
or better, etc?
First of all, the NuGet versioning error was solved with v0.4.42.
Second of all, I'm not 100% sure, but I believe that this project won't work with VS version < 2017, like 2015 in your case.
And also, I think but again am not sure, it requires that you use a new SDK-style csproj format. The newest Visual Studio 2017 version 15.7 has a built in migration tool.
Thanks for the prompt feedback. I'd say that's pretty much verified with the initial exceptions I received. I was wondering about that, actually. I haven't pursued 2017 migration yet, but it is something for me to chew on in the near term. Thanks again.
It's sadly true that the current codegeneration-roslyn project only allows code generation for SDK style projects. The framework they target is irrelevant and can be anything.
Good to know. Thanks for the awareness on that front.
That's
Framework 4.6.2
/.NET Standard
that should be inter-operable, correct? Doesn't work for me:I want to add code generation. I think that a Compile time only
Attribute
is probably best to signal that this should occur. TBD where that attribute should live, but I wonder about the line:Doesn't that sort of imply that the
Attribute
has a priori knowledge of the generator? In my case, I cannot guarantee users are on.NET Standard
/Core
yet, so what's the alternative? Seems like a potentially circular Assembly dependency in the making.