Repository navigation
Future of Add-Type #5725
Description
Current version of Add-Type cmdlet is partially ported on Roslyn from Dom. It is large breaking change. It is true for most of the parameters. Some parameters was related to Dom and was removed. Some parameters don't implemented. In fact, we already have a new cmdlet.
Before I push new enhancements I want discuss a few points. We could remove old things.
- public enum
Language
Should we keep JScript for backward compatibility?
Should we add FSharp for future?
Should we keep CSharpVersion1, CSharpVersion2 and so on? If yes should we add VisualBasicVersion9 and so on? Could we leave only CSharp and VisualBasic in the enum? Why anybody can want to use CSharpVersion1 in PowerShell?! I found nothing on GitHub - I think we should old elements.
Currently I have to add language family type with CSharp and VisualBasic internally. So I'd prefer simplifypublic enum Languageand don't use the new type and helper functions to translate these types. - Roslyn can accept parsing and compile options. It is different types for every language (currently CSharp and VusualBasic). Some options (not all) can be useful for Add-Type (language version, preprocessor variables).
How we can better expose the options? Generic or by language? The question related with previous one - with options we can specify the language version. We could Roslyn generic classes but they are not convenient to work in PowerShell. I have no conclusion. - Should we support creation new assembly without loading? Currently we always load created assembly, even with
-Passthrou. I think we could add-CompileOnlyswitch.
Activity
SteveL-MSFT commentedon Dec 27, 2017
Add-Typewas a big change to dotnetcore so I'm personally ok with not maintaining strict compatibility for legacy features that people don't use (with sufficient data).Ideally, we should use dynamic parameters per language.
I think adding a
-CompileOnlyswitch would be useful.HerbM commentedon Jan 6, 2018
Please do add FSharp.
Current versions of FSharp.Compiler.Codedom seem to be broken relative to incorrect version of FSharp.Core -- and no amount of installing packages for various versions had helped me -- or asking on FSharp Slack.
Whose problem would this be? Where should it be reported?
(I think it is stuck half-way between PowerShell & FSharp with no one to care.
iSazonov commentedon Jan 6, 2018
Herb Martin (@HerbM) Thanks for your feedback. I like this too. But I don't found FSharp classes in Roslyn repo. It seems it is a separate project. So my current plan is to remove a regression and add VisualBasic support. After that we could research in depth how add FSharp support.
daxian-dbw commentedon Jan 10, 2018
One correction:
-PassThrureturns the types that were added byAdd-Type, so the assembly has to be loaded when it's specified.LMA1980 commentedon Feb 24, 2018
Would it be possible to add PowerShell as a language to overcome the limitation link to the PowerShell's keyword Class?
iSazonov commentedon Feb 25, 2018
LMA1980 <aka ichiskaar> (@LMA1980) Could you add more information about your request?
LMA1980 commentedon Feb 25, 2018
Powershell now have the keyword class and enum. When using that method it allow to quickly generate simple class or even extend other classes.
Now the issue with such definition, they are only accessible to their Scope and currently they cannot be exported like a Function or a Cmdlet. (https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_classes?view=powershell-5)
With Add-Type -language PowerShell ... This would open up new capability without requiring wrapper like New-MyClass function solution to instanciate such object from outside of a Module scope.
iSazonov commentedon Feb 26, 2018
LMA1980 <aka ichiskaar> (@LMA1980) Thanks for clarify! It seems we have already such request (related with Import-Module). I couldn't find a quick the Issue.
iSazonov commentedon Feb 26, 2018
LMA1980 <aka ichiskaar> (@LMA1980) Please see related Issues #4713, #2964, #2963, #2505, #2449