-
Notifications
You must be signed in to change notification settings - Fork 74
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
Multi targeting #276
Multi targeting #276
Conversation
…ments into multiTargeting
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we have any system setup to test the separate targets? How will we know if we use a feature in one framework setting that doesn't work as expected? Or are compilation errors the only real concern.
Reviewed 2 of 4 files at r1.
Reviewable status: 2 of 4 files reviewed, 1 unresolved discussion (waiting on @andrewheumann and @ikeough)
src/Elements/Elements.csproj, line 4 at r1 (raw file):
<PropertyGroup> <TargetFrameworks>netstandard2.0;net472;netcoreapp2.1</TargetFrameworks>
Do we need all three of these? why netstandard2.0 AND netcoreapp2.1?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm glad you asked about this @wynged — In theory it's possible to set up multi-targeting tests, although I'm having a little trouble doing this. Currently all tests pass in .netstandard and it compiles in both, but so far I've been unable to get tests running in .net framework.
Reviewable status: 2 of 4 files reviewed, 1 unresolved discussion (waiting on @ikeough)
src/Elements/Elements.csproj, line 4 at r1 (raw file):
Previously, wynged (Eric Wassail) wrote…
Do we need all three of these? why netstandard2.0 AND netcoreapp2.1?
when @ikeough and I set this up we put in both, I forget why. @ikeough is there any reason to maintain netcoreapp2.1 as well?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reviewable status: 2 of 9 files reviewed, 8 unresolved discussions (waiting on @andrewheumann, @ikeough, and @wynged)
src/Elements/Elements.csproj, line 4 at r1 (raw file):
Previously, andrewheumann wrote…
when @ikeough and I set this up we put in both, I forget why. @ikeough is there any reason to maintain netcoreapp2.1 as well?
I don't think we need netcoreapp2.1
. netstandard2.0
should cover it.
src/Elements/Generate/TypeGenerator.cs, line 84 at r2 (raw file):
var schema = GetSchema(uri); var csharp = GenerateCodeForSchema(schema); Console.WriteLine($"Writing to {outPath}...");
"Generating type Foo in users/superdave/Foo.g.cs..."
src/Elements/Generate/TypeGenerator.cs, line 104 at r2 (raw file):
var schema = GetSchema(uri); var csharp = GenerateCodeForSchema(schema); if (csharp == null) continue;
Brackets
src/Elements/Generate/TypeGenerator.cs, line 152 at r2 (raw file):
/// </summary> /// <param name="uri">The web URL or file path to the schema JSON.</param> /// <returns></returns>
Remove empty <returns>
if you're not using it.
src/Elements/Generate/TypeGenerator.cs, line 244 at r2 (raw file):
/// </summary> /// <returns></returns> public static List<Type> GetLoadedTypeNames()
It seems that this should be List<Element> GetLoadedElementTypes()
src/Elements/Generate/TypeGenerator.cs, line 270 at r2 (raw file):
/// </summary> /// <returns></returns> public static string GetAssemblyFolder()
Does this need to be public?
test/Elements.Tests/Grid1dTests.cs, line 37 at r3 (raw file):
var pattern = new[] { 1.0, 1.5 }; #if NETCORE grid[3].DivideByPattern(pattern);
Why is this only allowed on .net core?
test/Elements.Tests/Grid1dTests.cs, line 228 at r3 (raw file):
} [IgnoreOnNetFrameworkFact]
Why are we ignoring these tests?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reviewable status: 2 of 9 files reviewed, 8 unresolved discussions (waiting on @ikeough and @wynged)
src/Elements/Elements.csproj, line 4 at r1 (raw file):
Previously, ikeough (Ian Keough) wrote…
I don't think we need
netcoreapp2.1
.netstandard2.0
should cover it.
Done.
src/Elements/Generate/TypeGenerator.cs, line 84 at r2 (raw file):
Previously, ikeough (Ian Keough) wrote…
"Generating type Foo in users/superdave/Foo.g.cs..."
Done.
src/Elements/Generate/TypeGenerator.cs, line 104 at r2 (raw file):
Previously, ikeough (Ian Keough) wrote…
Brackets
Done.
src/Elements/Generate/TypeGenerator.cs, line 152 at r2 (raw file):
Previously, ikeough (Ian Keough) wrote…
Remove empty
<returns>
if you're not using it.
Done.
src/Elements/Generate/TypeGenerator.cs, line 244 at r2 (raw file):
Previously, ikeough (Ian Keough) wrote…
It seems that this should be
List<Element> GetLoadedElementTypes()
but they're not elements -- they're element types. I'm not getting the instances of element, I'm just getting all the current element types that the active appdomain knows about.
src/Elements/Generate/TypeGenerator.cs, line 270 at r2 (raw file):
Previously, ikeough (Ian Keough) wrote…
Does this need to be public?
I was using it in Elements for Grasshopper but I don't anymore. I'll make it private again.
test/Elements.Tests/Grid1dTests.cs, line 37 at r3 (raw file):
Previously, ikeough (Ian Keough) wrote…
Why is this only allowed on .net core?
I was getting a bunch of System.Runtime version conflict errors building this test for framework. I wanted to at least make sure the test project BUILT under framework before trying to change stuff to be compatible. I think it has something to do with framework being less happy with me passing around Lists of named Tuples, but I'm not sure.
test/Elements.Tests/Grid1dTests.cs, line 228 at r3 (raw file):
Previously, ikeough (Ian Keough) wrote…
Why are we ignoring these tests?
Same reason as above -- these prevent compile under a framework build.
Is this PR going forward? |
Closing based on an internal conversation. We'll revisit when we have at least one more framework-based consumer. |
BACKGROUND:
DESCRIPTION:
Elements.Generate.TypeGenerator
to support the dynamic type compilation needs of the Grasshopper plug-inGuid id = Guid.Empty;
)TESTING:
FUTURE WORK:
This change is