Update of samples to latest Microsoft assemblies and Visual Studio#442
Update of samples to latest Microsoft assemblies and Visual Studio#442oleg-shilo merged 12 commits intooleg-shilo:masterfrom
Conversation
maettu-this
left a comment
There was a problem hiding this comment.
The additional input as mentioned in the PR.
maettu-this
left a comment
There was a problem hiding this comment.
One more finding/proposal.
There was a problem hiding this comment.
Thinking about the samples, how about splitting (Roslyn+CodeDom) such this project gets reduced to (Roslyn) and all CodeDom related functionality is demonstrated by (CodeDom)?
Rationale:
- Roslyn doesn't need to NuGet csc.exe, correct?
- More obvious to host app developer which parts need to be taken, depending on evaluator used.
|
I have just added to the PR by further cleaning up the .NET Framework sample projects. Please see commit messages for details. To conclude on this PR, please see proposals further above. |
|
I am merging it as is. But I am planning to rework the whole .NET Framework use case so there will be a reasonable change in the sample(s). |
Major rework f the .NET Framework samples. Triggered by #442 =================== Refactor compiler selection and CodeDom evaluator logic - Remove obsolete CompileOnServer and move compiler path logic from Globals to CodeDomEvaluator - Add DefaultNetFrameworkCompiler, SuppressDefaultNetFrameworkAssemblies, and MsNetComilersToolsetCompiler to CodeDomEvaluator - Update assembly reference logic to support suppressing default .NET Framework assemblies - Refactor Client.NET472 test code for clarity and coverage; remove NetCompiler.cs and related code - Update solution/project files to remove "Client.NET472 (Roslyn+CodeDom)" and add "Client.NET472" - Expand csc property documentation for clarity and platform details
Reworked and unified csc.exe probing for CodeDom compilation. Triggered by #434 and #442 ============= Improve compiler discovery and add SemanticVersion class Refactored compiler location logic into Globals with new methods for NuGet and SDK-based compilers. Introduced SemanticVersion class for parsing and comparing semantic versions, with comprehensive unit tests. Updated CodeDomEvaluator to handle .dll and .exe compilers correctly. Added Microsoft.Net.Sdk.Compilers.Toolset NuGet reference to Client.NET. Fixed minor bugs and improved process handling. Expanded documentation and updated build/test scripts.
@oleg-shilo, sounds reasonable. Do you intend to do this work as part of #440? If so, will you copy-paste the additional findings/proposals from this PR to that issue or shall I do so? Or will work be as part of a new issue? |
|
Yes, I have practically finished. working on #440. I treatedthis effort as a continuation of this very PR. The proposal from this PR is implemented (e.g. the NET Frx code sample has been collapsed into a single sample). The compiler is now coming from the NuGet package, even though the SDK distro is also detected as a fallback. Though packaging the compilers with the user app is yet to be documented. Is this what you mean? |
Yepp, exactly. I'll take a closer look at the reworked samples once I see #440 got closed and I find some time to do so. Thanks for all the efforts! |
|
I will close #440 only after 1 month without any post-release defect reports. This is the workflow I follow.
|
Hi Oleg,
This PR is related to #434 analysis. Please review the changes and adjust/refine as needed. I'll also add some comments with additional input.
Note that I have also tried to use the almost "latest" C# 13 with the NET472 samples:
Results in:
https://stackoverflow.com/questions/56651472/does-c-sharp-8-support-the-net-framework quite well explains on the possibilities and limitations of using C# 8+ with .NET Framework. Possible yes, but neither recommended nor without restrictions. I have tried to make this clearer in the CS-Script samples.
Best regards,
Matthias