-
Notifications
You must be signed in to change notification settings - Fork 8.1k
Fix for duplicate types in TypeTable #3141
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
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -1309,7 +1309,7 @@ public void Add(T item) | |
| } | ||
|
|
||
| /// <summary> | ||
| /// | ||
| /// Add items to this collection. | ||
| /// </summary> | ||
| /// <param name="items"></param> | ||
| public void Add(IEnumerable<T> items) | ||
|
|
@@ -1326,6 +1326,27 @@ public void Add(IEnumerable<T> items) | |
| } | ||
| } | ||
|
|
||
| /// <summary> | ||
| /// Special add for TypeTable type entries that removes redundant file entries. | ||
| /// </summary> | ||
| internal void AddTypeTableTypesInfo(IEnumerable<T> items) | ||
| { | ||
| if (typeof(T) != typeof(SessionStateTypeEntry)) { throw new PSInvalidOperationException(); } | ||
|
|
||
| lock (_syncObject) | ||
| { | ||
| foreach (var element in items) | ||
| { | ||
| var typeEntry = element as SessionStateTypeEntry; | ||
| if (typeEntry.TypeData != null) | ||
| { | ||
| // Skip type file entries. | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm not sure if the scenario is supported, but does
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Update-TypeData and Remove-TypeData work directly on TypeTable and nothing has changed there and the TypeTables remain the same. This bug is when passing the TypeTable to the ISS so I think it is Ok. But I am running regression tests to ensure nothing is broken.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I would be surprised if we have tests covering the scenario - I think you'll need to write some new tests.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. As near as I can tell these cmdlets have nothing to do with the bug I fixed. They affect the TypeTable directly (add/remove) but are not involved with ISS binding to a runspace where the fix is. Maybe I am missing something but I don't see a scenario that needs testing.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. But the TypeTable is shared. If one changes the TypeTable in one runspace, then uses that shared TypeTable to construct another runspace, does your code handle that correctly? I think this is a non-issue because changing a shared type table should not be allowed, but I was asking that you confirm that, preferably with tests because I wasn't confident your code was correct if it was allowed.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Ok, I understand you now. I agree that this is a non-issue, not necessarily because changing a shared type table is not allowed but because the TypeTable is consistent in how it stores types. But I'll add a test for this.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I verified that Update-TypeData and Remove-TypeData does not affect ISS TypeTable. I also verified that the code disallows a shared TypeTable in the ISS (unless it is the only entry), and added a test for this. |
||
| _internalCollection.Add(element); | ||
| } | ||
| } | ||
| } | ||
| } | ||
|
|
||
| /// <summary> | ||
| /// Get enumerator for this collection. | ||
| /// </summary> | ||
|
|
@@ -3851,7 +3872,12 @@ internal void UpdateTypes(ExecutionContext context, bool updateOnly) | |
| context.TypeTable = typeTable; | ||
|
|
||
| Types.Clear(); | ||
| Types.Add(typeTable.typesInfo); | ||
|
|
||
| // A TypeTable contains types info along with type file references used to create the types info, | ||
| // which is redundant information. When resused in a runspace the ISS unpacks the file types again | ||
| // resulting in duplicate types and duplication errors when processed. | ||
| // So use this special Add method to filter all types files found in the TypeTable. | ||
| Types.AddTypeTableTypesInfo(typeTable.typesInfo); | ||
|
|
||
| return; | ||
| } | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,13 @@ | ||
| <?xml version="1.0" encoding="utf-8" ?> | ||
|
|
||
| <Types> | ||
| <Type> | ||
| <Name>System.Array</Name> | ||
| <Members> | ||
| <AliasProperty> | ||
| <Name>Counts</Name> | ||
| <ReferencedMemberName>Length</ReferencedMemberName> | ||
| </AliasProperty> | ||
| </Members> | ||
| </Type> | ||
| </Types> |
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.
Your check at the start of the function means you can cast instead of using
as, which you should prefer because you're not testing iftypeEntryis null. And I suppose we don't allow addingnullentries?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 thought so too but a direct cast isn't allowed:
var typeEntry = (SessionStateTypeEntry)element;
"Cannot covert type T to SessionStateTypeEntry"
It looks like a runtime cast is needed. Or is there another way?
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 don't know why a cast is not allowed -
Tis even constrained to beInitialSessionStateEntry, so C# should be smart enough to allow the cast. Oh 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.
I also tried using a type constrained on the method but that failed as well because SessionStateTypeEntry is a sealed class which is disallowed as a constraint...