Skip to content
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

Consider switching to .NET SDK style projects #737

Closed
Barsonax opened this issue Jul 28, 2019 · 6 comments · Fixed by #744
Closed

Consider switching to .NET SDK style projects #737

Barsonax opened this issue Jul 28, 2019 · 6 comments · Fixed by #744
Assignees
Labels
DevTool Area: Development tools and environment Task ToDo that's neither a Bug, nor a Feature
Milestone

Comments

@Barsonax
Copy link
Member

Barsonax commented Jul 28, 2019

Summary

This is already a requirement for netstandard but we also have netframework projects that we could migrate to .NET sdk style projects. This is not strictly required but might still be preferable.

Analysis

  • Does not work for PCL's but these will be done when we migrate to netstandard
  • A issue was found in Switch From PCLs to .NET Standard #573 in the canvas unit tests when doing this. Not sure if this is the real cause though but just a heads up.
  • Much cleaner csprojs, like it will fit in 1 screen with no scrolling required.
  • Consistent style with the plugin projects
  • dotnet tooling support! (such as easily creating nuget packages with dotnet pack)
  • Needed for our future transition to .NET core.
@ilexp ilexp added DevTool Area: Development tools and environment Task ToDo that's neither a Bug, nor a Feature labels Jul 28, 2019
@ilexp ilexp added this to the C# / .NET Upgrade milestone Jul 28, 2019
@ilexp ilexp changed the title Consider switching to .NET sdk style projects Consider switching to .NET SDK style projects Jul 28, 2019
@Barsonax
Copy link
Member Author

You can use netframework as target in a net sdk style project however stuff like WPF, winforms, web applications etc are not supported yet.

Since duality is using winforms this is a bit of a bummer. However what we can do for now is upgrade all projects that do not require winforms.

Maybe when .NET core 3.0 is out winform support in sdk style projects (for netframework) will be there too.

@Barsonax
Copy link
Member Author

Barsonax commented Aug 17, 2019

Seems there are some more issues. Getting some failing unit tests when I changed DualityTests to be a net sdk style project. Branch can be found here:
https://github.com/Barsonax/duality/tree/feature/sdkcsprojs

We should first investigate this further before proceeding. We ran into these issues earlier but now we have a isolated branch with just the sdk style change it might be easier to find out whats going wrong here.

@Barsonax
Copy link
Member Author

Debugging the code both before and after this change resulted in this difference for the RenderRedSquare test:
Sdk style project:
image

Old style project:
image

Might have forgotten something when changing the csproj I think.

@Barsonax
Copy link
Member Author

Barsonax commented Aug 18, 2019

I think I got it figured out. Net sdk style projects output to a framework specific folder. In this case it would put the test dll in a net472 folder. When running the tests it will run in the context of this net472 folder and will only load plugins that are also in this folder.

The tests have some implicit dependencies on certain duality plugins so they now break.

This behavior can luckily be disabled by setting a property in the csproj. However iam not sure if we want such implicit dependencies though that might be a discussion for a different issue.

Might also be solved if we migrate all projects since they should all end up in a framework specific folder.

EDIT: solved it by adding in <AppendTargetFrameworkToOutputPath>false</AppendTargetFrameworkToOutputPath> to the csproj. This is only needed while we still have a mix of old and new style csprojs.

@Barsonax
Copy link
Member Author

We could also simply add tests that test if we are running the correct backends and not some dummy graphic backend. The tests assume this but its currently not clear.

@Barsonax
Copy link
Member Author

Easy way to add the required entries for resx files in a net sdk csproj:

  1. Add this to your csproj:
<Compile Update="**\*.Designer.cs">
	<AutoGen>True</AutoGen>
	<DesignTime>True</DesignTime>
	<DependentUpon>$([System.String]::Copy('%(FileName)').Replace('.Designer', '.resx'))</DependentUpon>
</Compile>
<EmbeddedResource Update="**\*.resx">
	<Generator>PublicResXFileCodeGenerator</Generator>
	<LastGenOutput>$([System.String]::Copy('%(FileName)')).Designer.cs</LastGenOutput>
</EmbeddedResource>
  1. Click save in visual studio. The required entries will be added.
  2. You can now remove the entries we added in step 1.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
DevTool Area: Development tools and environment Task ToDo that's neither a Bug, nor a Feature
Development

Successfully merging a pull request may close this issue.

2 participants