Skip to content

Add missing type forwards - #90669

Merged
ViktorHofer merged 8 commits into
mainfrom
ViktorHofer-patch-2
Aug 17, 2023
Merged

Add missing type forwards#90669
ViktorHofer merged 8 commits into
mainfrom
ViktorHofer-patch-2

Conversation

@ViktorHofer

@ViktorHoferViktorHofer commented Aug 16, 2023

Copy link
Copy Markdown
Member

Fixes#90578

IDispatchImplAttribute, IDispatchImplType and SetWin32ContextInIDispatchAttribute were removed with 9f1dd1a and 26a91ad

Those dropped types weren't flagged because APICompat only validates reference assemblies. We have three implementation only shim assemblies: mscorlib, System and System.Data. I verified that no other type forwards were lost between .NET 7 and .NET 8.

@ViktorHofer
Add missing type forwards
2509949
Fixes#90578
IDispatchImplAttribute, IDispatchImplType and SetWin32ContextInIDispatchAttribute were removed with 9f1dd1a and 26a91ad
Those dropped types weren't flagged because APICompat only validates reference assemblies. We have three implementation only shim assemblies: mscorlib, System and System.Data. I verified that no other type forwards were lost between .NET 7 and .NET 8.
@ViktorHofer
ViktorHofer requested review from a team and ericstjAugust 16, 2023 15:48
@ViktorHoferViktorHofer self-assigned this Aug 16, 2023
@ghost

ghost commented Aug 16, 2023

Copy link
Copy Markdown

Tagging subscribers to this area: @dotnet/area-infrastructure-libraries
See info in area-owners.md if you want to be subscribed.

Issue Details

Fixes #90578

IDispatchImplAttribute, IDispatchImplType and SetWin32ContextInIDispatchAttribute were removed with 9f1dd1a and 26a91ad

Those dropped types weren't flagged because APICompat only validates reference assemblies. We have three implementation only shim assemblies: mscorlib, System and System.Data. I verified that no other type forwards were lost between .NET 7 and .NET 8.

Author:ViktorHofer
Assignees:ViktorHofer
Labels:

area-Infrastructure-libraries

Milestone:-

@ViktorHofer

ViktorHofer commented Aug 16, 2023

Copy link
Copy Markdown
MemberAuthor

/backport to release/8.0-rc1

@github-actions

github-actionsBot commented Aug 16, 2023

Copy link
Copy Markdown
Contributor

Started backporting to release/8.0-rc1: https://github.com/dotnet/runtime/actions/runs/5881442922

@github-actionsgithub-actionsBot mentioned this pull request Aug 16, 2023
Merged
@ericstjericstj mentioned this pull request Aug 16, 2023
Merged
@ViktorHoferViktorHofer mentioned this pull request Aug 16, 2023
Closed
jkotas
jkotas reviewed Aug 16, 2023
View reviewed changes
Comment threadsrc/libraries/shims/mscorlib/src/mscorlib.cs Outdated
@jkotas

jkotas commented Aug 16, 2023

Copy link
Copy Markdown
Member

IDispatchImplAttribute, IDispatchImplType and SetWin32ContextInIDispatchAttribute

Do we need to add these (unused) types back for compat?

@jkotas

jkotas commented Aug 16, 2023

Copy link
Copy Markdown
Member

IDispatchImplAttribute, IDispatchImplType and SetWin32ContextInIDispatchAttribute

Do we need to add these (unused) types back for compat?

Both the types that you are adding the forwards for and the types that we happened to delete have same characteristics: Never exposed in .NET Core/5+ public surface, never actually used in .NET 5, included just to make compat shims work. If we are keeping them, we should keep all of them and undo the deletion.

@ViktorHofer

ViktorHofer commented Aug 16, 2023•
edited
Loading

Copy link
Copy Markdown
MemberAuthor

Do we need to add these (unused) types back for compat?

We could add them directly into mscorlib's implementation assembly as stubs (without type forwarding to System.Runtime.InteropServices) so that people only pay for them when they use the .NET Framework shims. cc @AaronRobinsonMSFT

It's not clear to me why they were added to the mscorlib runtime shim in the first place though. The mscorlib runtime shim was only created back then for binary formatter serialization payload compatibility. Those types might have unintentionally been added as part of that change...

@AaronRobinsonMSFT

AaronRobinsonMSFT commented Aug 16, 2023

Copy link
Copy Markdown
Member

We could add them directly into mscorlib's implementation assembly as stubs

Can someone clarify why/how these are coming up? As @jkotas mentioned and I did on the original PR, these types were never in a .NET Core ref assembly. There was no way for someone to target their code to a .NET Core TFM and compile successfully, right? That last part I am asking because I really thought that was true.

My preference here would be to not speak them ever again in a .NET Core scenario. I am unclear under what circumstances they would cause issues at this point.

@ViktorHofer

ViktorHofer commented Aug 16, 2023•
edited
Loading

Copy link
Copy Markdown
MemberAuthor

When loading a .NET Framework compiled assembly that uses these types on .NETCoreApp, you would see a TypeLoadException with their removal. These existed in mscorlib.dll in .NET Framework. In .NETCoreApp, we also have an mscorlib.dll assembly which is just a shim assembly that type forwards to the actual location (System.Runtime.InteropServices for the removed types).

@jkotas

jkotas commented Aug 16, 2023

Copy link
Copy Markdown
Member

The scenario is that you compiled a library for .NET Framework and then run that library on .NET Core. This is documented as .NET Framework compatibility mode: https://learn.microsoft.com/en-us/dotnet/core/porting/#net-framework-compatibility-mode

@ViktorHofer

ViktorHofer commented Aug 16, 2023•
edited
Loading

Copy link
Copy Markdown
MemberAuthor

I just pushed to the branch to experiment with what I mentioned above. Thoughts on that?

We could add them directly into mscorlib's implementation assembly as stubs (without type forwarding to System.Runtime.InteropServices) so that people only pay for them when they use the .NET Framework shims.

@AaronRobinsonMSFT

AaronRobinsonMSFT commented Aug 16, 2023

Copy link
Copy Markdown
Member

The scenario is that you compiled a library for .NET Framework and then run that library on .NET Core.

I have a hard time with this policy at the interop boundary. These APIs represent semantic behavior that is hard at the best of times to root out and in this case them becoming no-ops turns this into a really difficult support scenario. Personally, I think APIs that influence complex behavior (i.e., interop scenarios) should fail to load because users will have no idea what may or may not happen given the context of their usage in most cases.

I understand the policy in general, but I think interop here is best left to "fail to load" rather than "sure, why not?".

@jkotas

jkotas commented Aug 16, 2023

Copy link
Copy Markdown
Member

I understand the policy in general, but I think interop here is best left to "fail to load" rather than "sure, why not?".

If you would like to prefer this instead of adding the delete types back, it is fine with me - it needs a breaking change notification filled.

@ViktorHofer

ViktorHofer commented Aug 16, 2023•
edited
Loading

Copy link
Copy Markdown
MemberAuthor

I'm fine with that as well but regarding Jan's point above:

Both the types that you are adding the forwards for and the types that we happened to delete have same characteristics: Never exposed in .NET Core/5+ public surface, never actually used in .NET 5, included just to make compat shims work.

These other types, i.e. https://github.com/dotnet/runtime/blob/7a11cff914fa6fcf00eb59be33306e3826e8b958/src/libraries/System.Runtime.InteropServices/src/System/Runtime/InteropServices/RegistrationConnectionType.cs#L7C21-L7C21 aren't referenced anywhere and aren't exposed. Why do we keep those but delete the others?

@build-analysisbuild-analysisBot mentioned this pull request Aug 16, 2023
Closed
@AaronRobinsonMSFT

AaronRobinsonMSFT commented Aug 16, 2023

Copy link
Copy Markdown
Member

I understand the policy in general, but I think interop here is best left to "fail to load" rather than "sure, why not?".

If you would like to prefer this instead of adding the delete types back, it is fine with me - it needs a breaking change notification filled.

BCN: dotnet/docs#36729

@ViktorHofer
ViktorHofer merged commit 296a1d5 into mainAug 17, 2023
@ViktorHofer
ViktorHofer deleted the ViktorHofer-patch-2 branch August 17, 2023 07:12
@ghostghost locked as resolved and limited conversation to collaborators Sep 16, 2023
Sign up for freeto subscribe to this conversation on GitHub. Already have an account? Sign in.

Reviewers

@jkotasjkotasjkotas left review comments
@ericstjericstjericstj approved these changes
+1 more reviewer
@carlossanlopcarlossanlopcarlossanlop approved these changes
Reviewers whose approvals may not affect merge requirements

Assignees

@ViktorHoferViktorHofer

Labels

area-Infrastructure-libraries

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

NET8 breaking change due to TypeForwardedTo attribute missing for PEFileKinds

5 participants

@ViktorHofer@jkotas@AaronRobinsonMSFT@carlossanlop@ericstj
, 'i'); if (__m === '*' || __re.test(location.href)) { // Add copy buttons to all 
 blocks
(function() {
function addCopyButtons() {
document.querySelectorAll('pre code').forEach(function(codeBlock) {
if (codeBlock.parentElement.hasAttribute('data-copy-added')) return;
codeBlock.parentElement.setAttribute('data-copy-added', 'true');
var btn = document.createElement('button');
btn.textContent = 'Copy';
btn.style.cssText = 'position:absolute;top:4px;right:4px;padding:2px 8px;font-size:11px;background:#4ecdc4;border:none;border-radius:4px;color:#1a1a2e;cursor:pointer;opacity:0.7;transition:opacity 0.2s;';
btn.onmouseover = function() { this.style.opacity = '1'; };
btn.onmouseout = function() { this.style.opacity = '0.7'; };
btn.onclick = function() {
navigator.clipboard.writeText(codeBlock.textContent).then(function() {
btn.textContent = 'Copied!';
setTimeout(function() { btn.textContent = 'Copy'; }, 1500);
});
};
codeBlock.parentElement.style.position = 'relative';
codeBlock.parentElement.appendChild(btn);
});
}
addCopyButtons();
// Re-run on dynamic content
var observer = new MutationObserver(addCopyButtons);
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:Add Copy Buttons to Code Blocks]', __e); }
})();
(function(){
try {
var __m = "github.com";
var __re = new RegExp('^' + "github\\.com" + '
Add missing type forwards by ViktorHofer · Pull Request #90669 · dotnet/runtime · GitHub
Skip to content
Add missing type forwards - #90669
Merged
ViktorHofer merged 8 commits into
mainfrom 
ViktorHofer-patch-2
Aug 17, 2023
Merged
Add missing type forwards#90669
ViktorHofer merged 8 commits into
mainfrom 
ViktorHofer-patch-2
Conversation
@ViktorHofer
@ViktorHoferViktorHofer
commented
Aug 16, 2023

Copy link


Copy Markdown

Member
Fixes#90578
IDispatchImplAttribute, IDispatchImplType and SetWin32ContextInIDispatchAttribute were removed with 9f1dd1a and 26a91ad
Those dropped types weren't flagged because APICompat only validates reference assemblies. We have three implementation only shim assemblies: mscorlib, System and System.Data. I verified that no other type forwards were lost between .NET 7 and .NET 8.
@ViktorHofer
Add missing type forwards
2509949
Fixes#90578
IDispatchImplAttribute, IDispatchImplType and SetWin32ContextInIDispatchAttribute were removed with 9f1dd1a and 26a91ad
Those dropped types weren't flagged because APICompat only validates reference assemblies. We have three implementation only shim assemblies: mscorlib, System and System.Data. I verified that no other type forwards were lost between .NET 7 and .NET 8.
@ViktorHofer
ViktorHofer
requested review from
a team and ericstjAugust 16, 2023 15:48
@ViktorHoferViktorHofer
self-assigned this
Aug 16, 2023
@ghost
ghost
commented
Aug 16, 2023

Copy link


Copy Markdown

Tagging subscribers to this area: @dotnet/area-infrastructure-libraries

See info in area-owners.md if you want to be subscribed.
Issue Details
Fixes #90578
IDispatchImplAttribute, IDispatchImplType and SetWin32ContextInIDispatchAttribute were removed with 9f1dd1a and 26a91ad
Those dropped types weren't flagged because APICompat only validates reference assemblies. We have three implementation only shim assemblies: mscorlib, System and System.Data. I verified that no other type forwards were lost between .NET 7 and .NET 8.
Author:ViktorHofer
Assignees:ViktorHofer
Labels:
area-Infrastructure-libraries
Milestone:-
@ViktorHofer
ViktorHofer
commented
Aug 16, 2023

Copy link


Copy Markdown

MemberAuthor
/backport to release/8.0-rc1
@github-actions
github-actionsBot
commented
Aug 16, 2023

Copy link


Copy Markdown

Contributor
Started backporting to release/8.0-rc1: https://github.com/dotnet/runtime/actions/runs/5881442922
@github-actionsgithub-actionsBot
mentioned this pull request
Aug 16, 2023
 Merged

@ericstjericstj
mentioned this pull request
Aug 16, 2023
 Merged

@ViktorHoferViktorHofer
mentioned this pull request
Aug 16, 2023

Closed

jkotas
jkotas
reviewed
Aug 16, 2023
View reviewed changes
Comment threadsrc/libraries/shims/mscorlib/src/mscorlib.cs
Outdated

@jkotas
jkotas
commented
Aug 16, 2023

Copy link


Copy Markdown

Member
IDispatchImplAttribute, IDispatchImplType and SetWin32ContextInIDispatchAttribute
Do we need to add these (unused) types back for compat?
@jkotas
jkotas
commented
Aug 16, 2023

Copy link


Copy Markdown

Member
IDispatchImplAttribute, IDispatchImplType and SetWin32ContextInIDispatchAttribute
Do we need to add these (unused) types back for compat?
Both the types that you are adding the forwards for and the types that we happened to delete have same characteristics: Never exposed in .NET Core/5+ public surface, never actually used in .NET 5, included just to make compat shims work. If we are keeping them, we should keep all of them and undo the deletion.
@ViktorHofer
ViktorHofer
commented
Aug 16, 2023•

edited

Loading

Copy link


Copy Markdown

MemberAuthor
Do we need to add these (unused) types back for compat?
We could add them directly into mscorlib's implementation assembly as stubs (without type forwarding to System.Runtime.InteropServices) so that people only pay for them when they use the .NET Framework shims. cc @AaronRobinsonMSFT
It's not clear to me why they were added to the mscorlib runtime shim in the first place though. The mscorlib runtime shim was only created back then for binary formatter serialization payload compatibility. Those types might have unintentionally been added as part of that change...
@AaronRobinsonMSFT
AaronRobinsonMSFT
commented
Aug 16, 2023

Copy link


Copy Markdown

Member
We could add them directly into mscorlib's implementation assembly as stubs
Can someone clarify why/how these are coming up? As @jkotas mentioned and I did on the original PR, these types were never in a .NET Core ref assembly. There was no way for someone to target their code to a .NET Core TFM and compile successfully, right? That last part I am asking because I really thought that was true.
My preference here would be to not speak them ever again in a .NET Core scenario. I am unclear under what circumstances they would cause issues at this point.
@ViktorHofer
ViktorHofer
commented
Aug 16, 2023•

edited

Loading

Copy link


Copy Markdown

MemberAuthor
When loading a .NET Framework compiled assembly that uses these types on .NETCoreApp, you would see a TypeLoadException with their removal. These existed in mscorlib.dll in .NET Framework. In .NETCoreApp, we also have an mscorlib.dll assembly which is just a shim assembly that type forwards to the actual location (System.Runtime.InteropServices for the removed types).
@jkotas
jkotas
commented
Aug 16, 2023

Copy link


Copy Markdown

Member
The scenario is that you compiled a library for .NET Framework and then run that library on .NET Core. This is documented as .NET Framework compatibility mode: https://learn.microsoft.com/en-us/dotnet/core/porting/#net-framework-compatibility-mode
@ViktorHofer
ViktorHofer
commented
Aug 16, 2023•

edited

Loading

Copy link


Copy Markdown

MemberAuthor
I just pushed to the branch to experiment with what I mentioned above. Thoughts on that?
We could add them directly into mscorlib's implementation assembly as stubs (without type forwarding to System.Runtime.InteropServices) so that people only pay for them when they use the .NET Framework shims.
@AaronRobinsonMSFT
AaronRobinsonMSFT
commented
Aug 16, 2023

Copy link


Copy Markdown

Member
The scenario is that you compiled a library for .NET Framework and then run that library on .NET Core.
I have a hard time with this policy at the interop boundary. These APIs represent semantic behavior that is hard at the best of times to root out and in this case them becoming no-ops turns this into a really difficult support scenario. Personally, I think APIs that influence complex behavior (i.e., interop scenarios) should fail to load because users will have no idea what may or may not happen given the context of their usage in most cases.
I understand the policy in general, but I think interop here is best left to "fail to load" rather than "sure, why not?".
@jkotas
jkotas
commented
Aug 16, 2023

Copy link


Copy Markdown

Member
I understand the policy in general, but I think interop here is best left to "fail to load" rather than "sure, why not?".
If you would like to prefer this instead of adding the delete types back, it is fine with me - it needs a breaking change notification filled.
@ViktorHofer
ViktorHofer
commented
Aug 16, 2023•

edited

Loading

Copy link


Copy Markdown

MemberAuthor
I'm fine with that as well but regarding Jan's point above:
Both the types that you are adding the forwards for and the types that we happened to delete have same characteristics: Never exposed in .NET Core/5+ public surface, never actually used in .NET 5, included just to make compat shims work.
These other types, i.e. https://github.com/dotnet/runtime/blob/7a11cff914fa6fcf00eb59be33306e3826e8b958/src/libraries/System.Runtime.InteropServices/src/System/Runtime/InteropServices/RegistrationConnectionType.cs#L7C21-L7C21 aren't referenced anywhere and aren't exposed. Why do we keep those but delete the others?
@build-analysisbuild-analysisBot
mentioned this pull request
Aug 16, 2023

Closed

@AaronRobinsonMSFT
AaronRobinsonMSFT
commented
Aug 16, 2023

Copy link


Copy Markdown

Member
I understand the policy in general, but I think interop here is best left to "fail to load" rather than "sure, why not?".
If you would like to prefer this instead of adding the delete types back, it is fine with me - it needs a breaking change notification filled.
BCN: dotnet/docs#36729
@ViktorHofer
ViktorHofer
merged commit 296a1d5
into
mainAug 17, 2023
@ViktorHofer
ViktorHofer
deleted the

ViktorHofer-patch-2

branch
August 17, 2023 07:12
@ghostghost
locked as resolved and limited conversation to collaborators
Sep 16, 2023
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.


Reviewers

@jkotasjkotasjkotas left review comments
@ericstjericstjericstj approved these changes

+1 more reviewer

@carlossanlopcarlossanlopcarlossanlop approved these changes
Reviewers whose approvals may not affect merge requirements

Assignees

@ViktorHoferViktorHofer

Labels

area-Infrastructure-libraries

Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

NET8 breaking change due to TypeForwardedTo attribute missing for PEFileKinds


5 participants

@ViktorHofer@jkotas@AaronRobinsonMSFT@carlossanlop@ericstj

, 'i');
if (__m === '*' || __re.test(location.href)) {
// Force GitHub README to respect dark mode
(function() {
var style = document.createElement('style');
style.textContent = '
.markdown-body {
color-scheme: dark light;
}
.markdown-body pre { background: #161b22 !important; }
.markdown-body code { background: rgba(110, 118, 129, 0.4) !important; }
.markdown-body table th, .markdown-body table td { border-color: #30363d !important; }
.markdown-body img { background: #0d1117; }
.markdown-body blockquote { border-left-color: #8b949e; }
.markdown-body hr { border-color: #30363d; }
';
document.head.appendChild(style);
})();
}
} catch(__e) { console.warn('[Userscript:GitHub Dark Mode README Fix]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '
Add missing type forwards by ViktorHofer · Pull Request #90669 · dotnet/runtime · GitHub
Skip to content
Add missing type forwards - #90669
Merged
ViktorHofer merged 8 commits into
mainfrom 
ViktorHofer-patch-2
Aug 17, 2023
Merged
Add missing type forwards#90669
ViktorHofer merged 8 commits into
mainfrom 
ViktorHofer-patch-2
Conversation
@ViktorHofer
@ViktorHoferViktorHofer
commented
Aug 16, 2023

Copy link


Copy Markdown

Member
Fixes#90578
IDispatchImplAttribute, IDispatchImplType and SetWin32ContextInIDispatchAttribute were removed with 9f1dd1a and 26a91ad
Those dropped types weren't flagged because APICompat only validates reference assemblies. We have three implementation only shim assemblies: mscorlib, System and System.Data. I verified that no other type forwards were lost between .NET 7 and .NET 8.
@ViktorHofer
Add missing type forwards
2509949
Fixes#90578
IDispatchImplAttribute, IDispatchImplType and SetWin32ContextInIDispatchAttribute were removed with 9f1dd1a and 26a91ad
Those dropped types weren't flagged because APICompat only validates reference assemblies. We have three implementation only shim assemblies: mscorlib, System and System.Data. I verified that no other type forwards were lost between .NET 7 and .NET 8.
@ViktorHofer
ViktorHofer
requested review from
a team and ericstjAugust 16, 2023 15:48
@ViktorHoferViktorHofer
self-assigned this
Aug 16, 2023
@ghost
ghost
commented
Aug 16, 2023

Copy link


Copy Markdown

Tagging subscribers to this area: @dotnet/area-infrastructure-libraries

See info in area-owners.md if you want to be subscribed.
Issue Details
Fixes #90578
IDispatchImplAttribute, IDispatchImplType and SetWin32ContextInIDispatchAttribute were removed with 9f1dd1a and 26a91ad
Those dropped types weren't flagged because APICompat only validates reference assemblies. We have three implementation only shim assemblies: mscorlib, System and System.Data. I verified that no other type forwards were lost between .NET 7 and .NET 8.
Author:ViktorHofer
Assignees:ViktorHofer
Labels:
area-Infrastructure-libraries
Milestone:-
@ViktorHofer
ViktorHofer
commented
Aug 16, 2023

Copy link


Copy Markdown

MemberAuthor
/backport to release/8.0-rc1
@github-actions
github-actionsBot
commented
Aug 16, 2023

Copy link


Copy Markdown

Contributor
Started backporting to release/8.0-rc1: https://github.com/dotnet/runtime/actions/runs/5881442922
@github-actionsgithub-actionsBot
mentioned this pull request
Aug 16, 2023
 Merged

@ericstjericstj
mentioned this pull request
Aug 16, 2023
 Merged

@ViktorHoferViktorHofer
mentioned this pull request
Aug 16, 2023

Closed

jkotas
jkotas
reviewed
Aug 16, 2023
View reviewed changes
Comment threadsrc/libraries/shims/mscorlib/src/mscorlib.cs
Outdated

@jkotas
jkotas
commented
Aug 16, 2023

Copy link


Copy Markdown

Member
IDispatchImplAttribute, IDispatchImplType and SetWin32ContextInIDispatchAttribute
Do we need to add these (unused) types back for compat?
@jkotas
jkotas
commented
Aug 16, 2023

Copy link


Copy Markdown

Member
IDispatchImplAttribute, IDispatchImplType and SetWin32ContextInIDispatchAttribute
Do we need to add these (unused) types back for compat?
Both the types that you are adding the forwards for and the types that we happened to delete have same characteristics: Never exposed in .NET Core/5+ public surface, never actually used in .NET 5, included just to make compat shims work. If we are keeping them, we should keep all of them and undo the deletion.
@ViktorHofer
ViktorHofer
commented
Aug 16, 2023•

edited

Loading

Copy link


Copy Markdown

MemberAuthor
Do we need to add these (unused) types back for compat?
We could add them directly into mscorlib's implementation assembly as stubs (without type forwarding to System.Runtime.InteropServices) so that people only pay for them when they use the .NET Framework shims. cc @AaronRobinsonMSFT
It's not clear to me why they were added to the mscorlib runtime shim in the first place though. The mscorlib runtime shim was only created back then for binary formatter serialization payload compatibility. Those types might have unintentionally been added as part of that change...
@AaronRobinsonMSFT
AaronRobinsonMSFT
commented
Aug 16, 2023

Copy link


Copy Markdown

Member
We could add them directly into mscorlib's implementation assembly as stubs
Can someone clarify why/how these are coming up? As @jkotas mentioned and I did on the original PR, these types were never in a .NET Core ref assembly. There was no way for someone to target their code to a .NET Core TFM and compile successfully, right? That last part I am asking because I really thought that was true.
My preference here would be to not speak them ever again in a .NET Core scenario. I am unclear under what circumstances they would cause issues at this point.
@ViktorHofer
ViktorHofer
commented
Aug 16, 2023•

edited

Loading

Copy link


Copy Markdown

MemberAuthor
When loading a .NET Framework compiled assembly that uses these types on .NETCoreApp, you would see a TypeLoadException with their removal. These existed in mscorlib.dll in .NET Framework. In .NETCoreApp, we also have an mscorlib.dll assembly which is just a shim assembly that type forwards to the actual location (System.Runtime.InteropServices for the removed types).
@jkotas
jkotas
commented
Aug 16, 2023

Copy link


Copy Markdown

Member
The scenario is that you compiled a library for .NET Framework and then run that library on .NET Core. This is documented as .NET Framework compatibility mode: https://learn.microsoft.com/en-us/dotnet/core/porting/#net-framework-compatibility-mode
@ViktorHofer
ViktorHofer
commented
Aug 16, 2023•

edited

Loading

Copy link


Copy Markdown

MemberAuthor
I just pushed to the branch to experiment with what I mentioned above. Thoughts on that?
We could add them directly into mscorlib's implementation assembly as stubs (without type forwarding to System.Runtime.InteropServices) so that people only pay for them when they use the .NET Framework shims.
@AaronRobinsonMSFT
AaronRobinsonMSFT
commented
Aug 16, 2023

Copy link


Copy Markdown

Member
The scenario is that you compiled a library for .NET Framework and then run that library on .NET Core.
I have a hard time with this policy at the interop boundary. These APIs represent semantic behavior that is hard at the best of times to root out and in this case them becoming no-ops turns this into a really difficult support scenario. Personally, I think APIs that influence complex behavior (i.e., interop scenarios) should fail to load because users will have no idea what may or may not happen given the context of their usage in most cases.
I understand the policy in general, but I think interop here is best left to "fail to load" rather than "sure, why not?".
@jkotas
jkotas
commented
Aug 16, 2023

Copy link


Copy Markdown

Member
I understand the policy in general, but I think interop here is best left to "fail to load" rather than "sure, why not?".
If you would like to prefer this instead of adding the delete types back, it is fine with me - it needs a breaking change notification filled.
@ViktorHofer
ViktorHofer
commented
Aug 16, 2023•

edited

Loading

Copy link


Copy Markdown

MemberAuthor
I'm fine with that as well but regarding Jan's point above:
Both the types that you are adding the forwards for and the types that we happened to delete have same characteristics: Never exposed in .NET Core/5+ public surface, never actually used in .NET 5, included just to make compat shims work.
These other types, i.e. https://github.com/dotnet/runtime/blob/7a11cff914fa6fcf00eb59be33306e3826e8b958/src/libraries/System.Runtime.InteropServices/src/System/Runtime/InteropServices/RegistrationConnectionType.cs#L7C21-L7C21 aren't referenced anywhere and aren't exposed. Why do we keep those but delete the others?
@build-analysisbuild-analysisBot
mentioned this pull request
Aug 16, 2023

Closed

@AaronRobinsonMSFT
AaronRobinsonMSFT
commented
Aug 16, 2023

Copy link


Copy Markdown

Member
I understand the policy in general, but I think interop here is best left to "fail to load" rather than "sure, why not?".
If you would like to prefer this instead of adding the delete types back, it is fine with me - it needs a breaking change notification filled.
BCN: dotnet/docs#36729
@ViktorHofer
ViktorHofer
merged commit 296a1d5
into
mainAug 17, 2023
@ViktorHofer
ViktorHofer
deleted the

ViktorHofer-patch-2

branch
August 17, 2023 07:12
@ghostghost
locked as resolved and limited conversation to collaborators
Sep 16, 2023
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.


Reviewers

@jkotasjkotasjkotas left review comments
@ericstjericstjericstj approved these changes

+1 more reviewer

@carlossanlopcarlossanlopcarlossanlop approved these changes
Reviewers whose approvals may not affect merge requirements

Assignees

@ViktorHoferViktorHofer

Labels

area-Infrastructure-libraries

Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

NET8 breaking change due to TypeForwardedTo attribute missing for PEFileKinds


5 participants

@ViktorHofer@jkotas@AaronRobinsonMSFT@carlossanlop@ericstj

, 'i');
if (__m === '*' || __re.test(location.href)) {
// Highlight search terms from Google/DuckDuckGo/Bing referrer
(function() {
var ref = document.referrer;
var terms = [];
if (ref.includes('google.com') || ref.includes('duckduckgo.com') || ref.includes('bing.com')) {
var url = new URL(ref);
var q = url.searchParams.get('q') || url.searchParams.get('p');
if (q) {
terms = q.split(/\s+/).filter(function(t) { return t.length > 2; });
}
}
if (terms.length === 0) return;
var style = document.createElement('style');
style.textContent = '.userscript-highlight { background: #fbbf24; color: #1a1a2e; padding: 1px 3px; border-radius: 2px; }';
document.head.appendChild(style);
function highlight(node) {
if (node.nodeType === 3) { // text node
var text = node.textContent;
var found = false;
terms.forEach(function(term) {
var regex = new RegExp('(' + term.replace(/[.*+?^${}()|[\]\\]/g, '\\') + ')', 'gi');
if (regex.test(text)) {
found = true;
var frag = document.createDocumentFragment();
var parts = text.split(regex);
parts.forEach(function(part, i) {
if (i % 2 === 0) {
frag.appendChild(document.createTextNode(part));
} else {
var span = document.createElement('span');
span.className = 'userscript-highlight';
span.textContent = part;
frag.appendChild(span);
}
});
node.parentNode.replaceChild(frag, node);
}
});
} else if (node.nodeType === 1 && node.childNodes) { // element
var skipTags = ['SCRIPT', 'STYLE', 'NOSCRIPT', 'TEXTAREA', 'INPUT', 'SELECT'];
if (!skipTags.includes(node.tagName)) {
Array.from(node.childNodes).forEach(highlight);
}
}
}
highlight(document.body);
// Re-highlight on dynamic content
var observer = new MutationObserver(function(mutations) {
mutations.forEach(function(m) {
m.addedNodes.forEach(function(node) {
if (node.nodeType === 1 || node.nodeType === 3) highlight(node);
});
});
});
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:Highlight Search Terms]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '
Add missing type forwards by ViktorHofer · Pull Request #90669 · dotnet/runtime · GitHub
Skip to content
Add missing type forwards - #90669
Merged
ViktorHofer merged 8 commits into
mainfrom 
ViktorHofer-patch-2
Aug 17, 2023
Merged
Add missing type forwards#90669
ViktorHofer merged 8 commits into
mainfrom 
ViktorHofer-patch-2
Conversation
@ViktorHofer
@ViktorHoferViktorHofer
commented
Aug 16, 2023

Copy link


Copy Markdown

Member
Fixes#90578
IDispatchImplAttribute, IDispatchImplType and SetWin32ContextInIDispatchAttribute were removed with 9f1dd1a and 26a91ad
Those dropped types weren't flagged because APICompat only validates reference assemblies. We have three implementation only shim assemblies: mscorlib, System and System.Data. I verified that no other type forwards were lost between .NET 7 and .NET 8.
@ViktorHofer
Add missing type forwards
2509949
Fixes#90578
IDispatchImplAttribute, IDispatchImplType and SetWin32ContextInIDispatchAttribute were removed with 9f1dd1a and 26a91ad
Those dropped types weren't flagged because APICompat only validates reference assemblies. We have three implementation only shim assemblies: mscorlib, System and System.Data. I verified that no other type forwards were lost between .NET 7 and .NET 8.
@ViktorHofer
ViktorHofer
requested review from
a team and ericstjAugust 16, 2023 15:48
@ViktorHoferViktorHofer
self-assigned this
Aug 16, 2023
@ghost
ghost
commented
Aug 16, 2023

Copy link


Copy Markdown

Tagging subscribers to this area: @dotnet/area-infrastructure-libraries

See info in area-owners.md if you want to be subscribed.
Issue Details
Fixes #90578
IDispatchImplAttribute, IDispatchImplType and SetWin32ContextInIDispatchAttribute were removed with 9f1dd1a and 26a91ad
Those dropped types weren't flagged because APICompat only validates reference assemblies. We have three implementation only shim assemblies: mscorlib, System and System.Data. I verified that no other type forwards were lost between .NET 7 and .NET 8.
Author:ViktorHofer
Assignees:ViktorHofer
Labels:
area-Infrastructure-libraries
Milestone:-
@ViktorHofer
ViktorHofer
commented
Aug 16, 2023

Copy link


Copy Markdown

MemberAuthor
/backport to release/8.0-rc1
@github-actions
github-actionsBot
commented
Aug 16, 2023

Copy link


Copy Markdown

Contributor
Started backporting to release/8.0-rc1: https://github.com/dotnet/runtime/actions/runs/5881442922
@github-actionsgithub-actionsBot
mentioned this pull request
Aug 16, 2023
 Merged

@ericstjericstj
mentioned this pull request
Aug 16, 2023
 Merged

@ViktorHoferViktorHofer
mentioned this pull request
Aug 16, 2023

Closed

jkotas
jkotas
reviewed
Aug 16, 2023
View reviewed changes
Comment threadsrc/libraries/shims/mscorlib/src/mscorlib.cs
Outdated

@jkotas
jkotas
commented
Aug 16, 2023

Copy link


Copy Markdown

Member
IDispatchImplAttribute, IDispatchImplType and SetWin32ContextInIDispatchAttribute
Do we need to add these (unused) types back for compat?
@jkotas
jkotas
commented
Aug 16, 2023

Copy link


Copy Markdown

Member
IDispatchImplAttribute, IDispatchImplType and SetWin32ContextInIDispatchAttribute
Do we need to add these (unused) types back for compat?
Both the types that you are adding the forwards for and the types that we happened to delete have same characteristics: Never exposed in .NET Core/5+ public surface, never actually used in .NET 5, included just to make compat shims work. If we are keeping them, we should keep all of them and undo the deletion.
@ViktorHofer
ViktorHofer
commented
Aug 16, 2023•

edited

Loading

Copy link


Copy Markdown

MemberAuthor
Do we need to add these (unused) types back for compat?
We could add them directly into mscorlib's implementation assembly as stubs (without type forwarding to System.Runtime.InteropServices) so that people only pay for them when they use the .NET Framework shims. cc @AaronRobinsonMSFT
It's not clear to me why they were added to the mscorlib runtime shim in the first place though. The mscorlib runtime shim was only created back then for binary formatter serialization payload compatibility. Those types might have unintentionally been added as part of that change...
@AaronRobinsonMSFT
AaronRobinsonMSFT
commented
Aug 16, 2023

Copy link


Copy Markdown

Member
We could add them directly into mscorlib's implementation assembly as stubs
Can someone clarify why/how these are coming up? As @jkotas mentioned and I did on the original PR, these types were never in a .NET Core ref assembly. There was no way for someone to target their code to a .NET Core TFM and compile successfully, right? That last part I am asking because I really thought that was true.
My preference here would be to not speak them ever again in a .NET Core scenario. I am unclear under what circumstances they would cause issues at this point.
@ViktorHofer
ViktorHofer
commented
Aug 16, 2023•

edited

Loading

Copy link


Copy Markdown

MemberAuthor
When loading a .NET Framework compiled assembly that uses these types on .NETCoreApp, you would see a TypeLoadException with their removal. These existed in mscorlib.dll in .NET Framework. In .NETCoreApp, we also have an mscorlib.dll assembly which is just a shim assembly that type forwards to the actual location (System.Runtime.InteropServices for the removed types).
@jkotas
jkotas
commented
Aug 16, 2023

Copy link


Copy Markdown

Member
The scenario is that you compiled a library for .NET Framework and then run that library on .NET Core. This is documented as .NET Framework compatibility mode: https://learn.microsoft.com/en-us/dotnet/core/porting/#net-framework-compatibility-mode
@ViktorHofer
ViktorHofer
commented
Aug 16, 2023•

edited

Loading

Copy link


Copy Markdown

MemberAuthor
I just pushed to the branch to experiment with what I mentioned above. Thoughts on that?
We could add them directly into mscorlib's implementation assembly as stubs (without type forwarding to System.Runtime.InteropServices) so that people only pay for them when they use the .NET Framework shims.
@AaronRobinsonMSFT
AaronRobinsonMSFT
commented
Aug 16, 2023

Copy link


Copy Markdown

Member
The scenario is that you compiled a library for .NET Framework and then run that library on .NET Core.
I have a hard time with this policy at the interop boundary. These APIs represent semantic behavior that is hard at the best of times to root out and in this case them becoming no-ops turns this into a really difficult support scenario. Personally, I think APIs that influence complex behavior (i.e., interop scenarios) should fail to load because users will have no idea what may or may not happen given the context of their usage in most cases.
I understand the policy in general, but I think interop here is best left to "fail to load" rather than "sure, why not?".
@jkotas
jkotas
commented
Aug 16, 2023

Copy link


Copy Markdown

Member
I understand the policy in general, but I think interop here is best left to "fail to load" rather than "sure, why not?".
If you would like to prefer this instead of adding the delete types back, it is fine with me - it needs a breaking change notification filled.
@ViktorHofer
ViktorHofer
commented
Aug 16, 2023•

edited

Loading

Copy link


Copy Markdown

MemberAuthor
I'm fine with that as well but regarding Jan's point above:
Both the types that you are adding the forwards for and the types that we happened to delete have same characteristics: Never exposed in .NET Core/5+ public surface, never actually used in .NET 5, included just to make compat shims work.
These other types, i.e. https://github.com/dotnet/runtime/blob/7a11cff914fa6fcf00eb59be33306e3826e8b958/src/libraries/System.Runtime.InteropServices/src/System/Runtime/InteropServices/RegistrationConnectionType.cs#L7C21-L7C21 aren't referenced anywhere and aren't exposed. Why do we keep those but delete the others?
@build-analysisbuild-analysisBot
mentioned this pull request
Aug 16, 2023

Closed

@AaronRobinsonMSFT
AaronRobinsonMSFT
commented
Aug 16, 2023

Copy link


Copy Markdown

Member
I understand the policy in general, but I think interop here is best left to "fail to load" rather than "sure, why not?".
If you would like to prefer this instead of adding the delete types back, it is fine with me - it needs a breaking change notification filled.
BCN: dotnet/docs#36729
@ViktorHofer
ViktorHofer
merged commit 296a1d5
into
mainAug 17, 2023
@ViktorHofer
ViktorHofer
deleted the

ViktorHofer-patch-2

branch
August 17, 2023 07:12
@ghostghost
locked as resolved and limited conversation to collaborators
Sep 16, 2023
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.


Reviewers

@jkotasjkotasjkotas left review comments
@ericstjericstjericstj approved these changes

+1 more reviewer

@carlossanlopcarlossanlopcarlossanlop approved these changes
Reviewers whose approvals may not affect merge requirements

Assignees

@ViktorHoferViktorHofer

Labels

area-Infrastructure-libraries

Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

NET8 breaking change due to TypeForwardedTo attribute missing for PEFileKinds


5 participants

@ViktorHofer@jkotas@AaronRobinsonMSFT@carlossanlop@ericstj

, 'i');
if (__m === '*' || __re.test(location.href)) {
// Strip utm_, fbclid, gclid, etc. from all links on page
(function() {
var trackingParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content',
'fbclid', 'gclid', 'dclid', 'msclkid', 'yclid',
'ref', 'ref_src', 'source', 'medium', 'campaign'];
function cleanUrl(url) {
try {
var u = new URL(url, window.location.origin);
var changed = false;
trackingParams.forEach(function(p) {
if (u.searchParams.has(p)) {
u.searchParams.delete(p);
changed = true;
}
});
return changed ? u.toString() : url;
} catch (e) {
return url;
}
}
function cleanLinks() {
document.querySelectorAll('a[href]').forEach(function(a) {
var clean = cleanUrl(a.href);
if (clean !== a.href) a.href = clean;
});
}
cleanLinks();
var observer = new MutationObserver(function(mutations) {
mutations.forEach(function(m) {
m.addedNodes.forEach(function(node) {
if (node.nodeType === 1) {
if (node.tagName === 'A') cleanLinks();
node.querySelectorAll('a[href]').forEach(function(a) {
var clean = cleanUrl(a.href);
if (clean !== a.href) a.href = clean;
});
}
});
});
});
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:Remove Tracking Parameters from Links]', __e); }
})();
(function(){
try {
var __m = "youtube.com";
var __re = new RegExp('^' + "youtube\\.com" + '
Add missing type forwards by ViktorHofer · Pull Request #90669 · dotnet/runtime · GitHub
Skip to content
Add missing type forwards - #90669
Merged
ViktorHofer merged 8 commits into
mainfrom 
ViktorHofer-patch-2
Aug 17, 2023
Merged
Add missing type forwards#90669
ViktorHofer merged 8 commits into
mainfrom 
ViktorHofer-patch-2
Conversation
@ViktorHofer
@ViktorHoferViktorHofer
commented
Aug 16, 2023

Copy link


Copy Markdown

Member
Fixes#90578
IDispatchImplAttribute, IDispatchImplType and SetWin32ContextInIDispatchAttribute were removed with 9f1dd1a and 26a91ad
Those dropped types weren't flagged because APICompat only validates reference assemblies. We have three implementation only shim assemblies: mscorlib, System and System.Data. I verified that no other type forwards were lost between .NET 7 and .NET 8.
@ViktorHofer
Add missing type forwards
2509949
Fixes#90578
IDispatchImplAttribute, IDispatchImplType and SetWin32ContextInIDispatchAttribute were removed with 9f1dd1a and 26a91ad
Those dropped types weren't flagged because APICompat only validates reference assemblies. We have three implementation only shim assemblies: mscorlib, System and System.Data. I verified that no other type forwards were lost between .NET 7 and .NET 8.
@ViktorHofer
ViktorHofer
requested review from
a team and ericstjAugust 16, 2023 15:48
@ViktorHoferViktorHofer
self-assigned this
Aug 16, 2023
@ghost
ghost
commented
Aug 16, 2023

Copy link


Copy Markdown

Tagging subscribers to this area: @dotnet/area-infrastructure-libraries

See info in area-owners.md if you want to be subscribed.
Issue Details
Fixes #90578
IDispatchImplAttribute, IDispatchImplType and SetWin32ContextInIDispatchAttribute were removed with 9f1dd1a and 26a91ad
Those dropped types weren't flagged because APICompat only validates reference assemblies. We have three implementation only shim assemblies: mscorlib, System and System.Data. I verified that no other type forwards were lost between .NET 7 and .NET 8.
Author:ViktorHofer
Assignees:ViktorHofer
Labels:
area-Infrastructure-libraries
Milestone:-
@ViktorHofer
ViktorHofer
commented
Aug 16, 2023

Copy link


Copy Markdown

MemberAuthor
/backport to release/8.0-rc1
@github-actions
github-actionsBot
commented
Aug 16, 2023

Copy link


Copy Markdown

Contributor
Started backporting to release/8.0-rc1: https://github.com/dotnet/runtime/actions/runs/5881442922
@github-actionsgithub-actionsBot
mentioned this pull request
Aug 16, 2023
 Merged

@ericstjericstj
mentioned this pull request
Aug 16, 2023
 Merged

@ViktorHoferViktorHofer
mentioned this pull request
Aug 16, 2023

Closed

jkotas
jkotas
reviewed
Aug 16, 2023
View reviewed changes
Comment threadsrc/libraries/shims/mscorlib/src/mscorlib.cs
Outdated

@jkotas
jkotas
commented
Aug 16, 2023

Copy link


Copy Markdown

Member
IDispatchImplAttribute, IDispatchImplType and SetWin32ContextInIDispatchAttribute
Do we need to add these (unused) types back for compat?
@jkotas
jkotas
commented
Aug 16, 2023

Copy link


Copy Markdown

Member
IDispatchImplAttribute, IDispatchImplType and SetWin32ContextInIDispatchAttribute
Do we need to add these (unused) types back for compat?
Both the types that you are adding the forwards for and the types that we happened to delete have same characteristics: Never exposed in .NET Core/5+ public surface, never actually used in .NET 5, included just to make compat shims work. If we are keeping them, we should keep all of them and undo the deletion.
@ViktorHofer
ViktorHofer
commented
Aug 16, 2023•

edited

Loading

Copy link


Copy Markdown

MemberAuthor
Do we need to add these (unused) types back for compat?
We could add them directly into mscorlib's implementation assembly as stubs (without type forwarding to System.Runtime.InteropServices) so that people only pay for them when they use the .NET Framework shims. cc @AaronRobinsonMSFT
It's not clear to me why they were added to the mscorlib runtime shim in the first place though. The mscorlib runtime shim was only created back then for binary formatter serialization payload compatibility. Those types might have unintentionally been added as part of that change...
@AaronRobinsonMSFT
AaronRobinsonMSFT
commented
Aug 16, 2023

Copy link


Copy Markdown

Member
We could add them directly into mscorlib's implementation assembly as stubs
Can someone clarify why/how these are coming up? As @jkotas mentioned and I did on the original PR, these types were never in a .NET Core ref assembly. There was no way for someone to target their code to a .NET Core TFM and compile successfully, right? That last part I am asking because I really thought that was true.
My preference here would be to not speak them ever again in a .NET Core scenario. I am unclear under what circumstances they would cause issues at this point.
@ViktorHofer
ViktorHofer
commented
Aug 16, 2023•

edited

Loading

Copy link


Copy Markdown

MemberAuthor
When loading a .NET Framework compiled assembly that uses these types on .NETCoreApp, you would see a TypeLoadException with their removal. These existed in mscorlib.dll in .NET Framework. In .NETCoreApp, we also have an mscorlib.dll assembly which is just a shim assembly that type forwards to the actual location (System.Runtime.InteropServices for the removed types).
@jkotas
jkotas
commented
Aug 16, 2023

Copy link


Copy Markdown

Member
The scenario is that you compiled a library for .NET Framework and then run that library on .NET Core. This is documented as .NET Framework compatibility mode: https://learn.microsoft.com/en-us/dotnet/core/porting/#net-framework-compatibility-mode
@ViktorHofer
ViktorHofer
commented
Aug 16, 2023•

edited

Loading

Copy link


Copy Markdown

MemberAuthor
I just pushed to the branch to experiment with what I mentioned above. Thoughts on that?
We could add them directly into mscorlib's implementation assembly as stubs (without type forwarding to System.Runtime.InteropServices) so that people only pay for them when they use the .NET Framework shims.
@AaronRobinsonMSFT
AaronRobinsonMSFT
commented
Aug 16, 2023

Copy link


Copy Markdown

Member
The scenario is that you compiled a library for .NET Framework and then run that library on .NET Core.
I have a hard time with this policy at the interop boundary. These APIs represent semantic behavior that is hard at the best of times to root out and in this case them becoming no-ops turns this into a really difficult support scenario. Personally, I think APIs that influence complex behavior (i.e., interop scenarios) should fail to load because users will have no idea what may or may not happen given the context of their usage in most cases.
I understand the policy in general, but I think interop here is best left to "fail to load" rather than "sure, why not?".
@jkotas
jkotas
commented
Aug 16, 2023

Copy link


Copy Markdown

Member
I understand the policy in general, but I think interop here is best left to "fail to load" rather than "sure, why not?".
If you would like to prefer this instead of adding the delete types back, it is fine with me - it needs a breaking change notification filled.
@ViktorHofer
ViktorHofer
commented
Aug 16, 2023•

edited

Loading

Copy link


Copy Markdown

MemberAuthor
I'm fine with that as well but regarding Jan's point above:
Both the types that you are adding the forwards for and the types that we happened to delete have same characteristics: Never exposed in .NET Core/5+ public surface, never actually used in .NET 5, included just to make compat shims work.
These other types, i.e. https://github.com/dotnet/runtime/blob/7a11cff914fa6fcf00eb59be33306e3826e8b958/src/libraries/System.Runtime.InteropServices/src/System/Runtime/InteropServices/RegistrationConnectionType.cs#L7C21-L7C21 aren't referenced anywhere and aren't exposed. Why do we keep those but delete the others?
@build-analysisbuild-analysisBot
mentioned this pull request
Aug 16, 2023

Closed

@AaronRobinsonMSFT
AaronRobinsonMSFT
commented
Aug 16, 2023

Copy link


Copy Markdown

Member
I understand the policy in general, but I think interop here is best left to "fail to load" rather than "sure, why not?".
If you would like to prefer this instead of adding the delete types back, it is fine with me - it needs a breaking change notification filled.
BCN: dotnet/docs#36729
@ViktorHofer
ViktorHofer
merged commit 296a1d5
into
mainAug 17, 2023
@ViktorHofer
ViktorHofer
deleted the

ViktorHofer-patch-2

branch
August 17, 2023 07:12
@ghostghost
locked as resolved and limited conversation to collaborators
Sep 16, 2023
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.


Reviewers

@jkotasjkotasjkotas left review comments
@ericstjericstjericstj approved these changes

+1 more reviewer

@carlossanlopcarlossanlopcarlossanlop approved these changes
Reviewers whose approvals may not affect merge requirements

Assignees

@ViktorHoferViktorHofer

Labels

area-Infrastructure-libraries

Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

NET8 breaking change due to TypeForwardedTo attribute missing for PEFileKinds


5 participants

@ViktorHofer@jkotas@AaronRobinsonMSFT@carlossanlop@ericstj

, 'i');
if (__m === '*' || __re.test(location.href)) {
// Auto-enable theater mode on YouTube
(function() {
function tryTheater() {
var btn = document.querySelector('button[aria-label="Theater mode"], ytd-player #player button[title="Theater mode"]');
if (btn && !btn.classList.contains('activated')) {
btn.click();
}
}
// Try immediately
tryTheater();
// Try after navigation (SPA)
var lastUrl = location.href;
setInterval(function() {
if (location.href !== lastUrl) {
lastUrl = location.href;
setTimeout(tryTheater, 500);
}
}, 1000);
// Also try on player load
var observer = new MutationObserver(tryTheater);
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:YouTube Theater Mode Default]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '
Add missing type forwards by ViktorHofer · Pull Request #90669 · dotnet/runtime · GitHub
Skip to content
Add missing type forwards - #90669
Merged
ViktorHofer merged 8 commits into
mainfrom 
ViktorHofer-patch-2
Aug 17, 2023
Merged
Add missing type forwards#90669
ViktorHofer merged 8 commits into
mainfrom 
ViktorHofer-patch-2
Conversation
@ViktorHofer
@ViktorHoferViktorHofer
commented
Aug 16, 2023

Copy link


Copy Markdown

Member
Fixes#90578
IDispatchImplAttribute, IDispatchImplType and SetWin32ContextInIDispatchAttribute were removed with 9f1dd1a and 26a91ad
Those dropped types weren't flagged because APICompat only validates reference assemblies. We have three implementation only shim assemblies: mscorlib, System and System.Data. I verified that no other type forwards were lost between .NET 7 and .NET 8.
@ViktorHofer
Add missing type forwards
2509949
Fixes#90578
IDispatchImplAttribute, IDispatchImplType and SetWin32ContextInIDispatchAttribute were removed with 9f1dd1a and 26a91ad
Those dropped types weren't flagged because APICompat only validates reference assemblies. We have three implementation only shim assemblies: mscorlib, System and System.Data. I verified that no other type forwards were lost between .NET 7 and .NET 8.
@ViktorHofer
ViktorHofer
requested review from
a team and ericstjAugust 16, 2023 15:48
@ViktorHoferViktorHofer
self-assigned this
Aug 16, 2023
@ghost
ghost
commented
Aug 16, 2023

Copy link


Copy Markdown

Tagging subscribers to this area: @dotnet/area-infrastructure-libraries

See info in area-owners.md if you want to be subscribed.
Issue Details
Fixes #90578
IDispatchImplAttribute, IDispatchImplType and SetWin32ContextInIDispatchAttribute were removed with 9f1dd1a and 26a91ad
Those dropped types weren't flagged because APICompat only validates reference assemblies. We have three implementation only shim assemblies: mscorlib, System and System.Data. I verified that no other type forwards were lost between .NET 7 and .NET 8.
Author:ViktorHofer
Assignees:ViktorHofer
Labels:
area-Infrastructure-libraries
Milestone:-
@ViktorHofer
ViktorHofer
commented
Aug 16, 2023

Copy link


Copy Markdown

MemberAuthor
/backport to release/8.0-rc1
@github-actions
github-actionsBot
commented
Aug 16, 2023

Copy link


Copy Markdown

Contributor
Started backporting to release/8.0-rc1: https://github.com/dotnet/runtime/actions/runs/5881442922
@github-actionsgithub-actionsBot
mentioned this pull request
Aug 16, 2023
 Merged

@ericstjericstj
mentioned this pull request
Aug 16, 2023
 Merged

@ViktorHoferViktorHofer
mentioned this pull request
Aug 16, 2023

Closed

jkotas
jkotas
reviewed
Aug 16, 2023
View reviewed changes
Comment threadsrc/libraries/shims/mscorlib/src/mscorlib.cs
Outdated

@jkotas
jkotas
commented
Aug 16, 2023

Copy link


Copy Markdown

Member
IDispatchImplAttribute, IDispatchImplType and SetWin32ContextInIDispatchAttribute
Do we need to add these (unused) types back for compat?
@jkotas
jkotas
commented
Aug 16, 2023

Copy link


Copy Markdown

Member
IDispatchImplAttribute, IDispatchImplType and SetWin32ContextInIDispatchAttribute
Do we need to add these (unused) types back for compat?
Both the types that you are adding the forwards for and the types that we happened to delete have same characteristics: Never exposed in .NET Core/5+ public surface, never actually used in .NET 5, included just to make compat shims work. If we are keeping them, we should keep all of them and undo the deletion.
@ViktorHofer
ViktorHofer
commented
Aug 16, 2023•

edited

Loading

Copy link


Copy Markdown

MemberAuthor
Do we need to add these (unused) types back for compat?
We could add them directly into mscorlib's implementation assembly as stubs (without type forwarding to System.Runtime.InteropServices) so that people only pay for them when they use the .NET Framework shims. cc @AaronRobinsonMSFT
It's not clear to me why they were added to the mscorlib runtime shim in the first place though. The mscorlib runtime shim was only created back then for binary formatter serialization payload compatibility. Those types might have unintentionally been added as part of that change...
@AaronRobinsonMSFT
AaronRobinsonMSFT
commented
Aug 16, 2023

Copy link


Copy Markdown

Member
We could add them directly into mscorlib's implementation assembly as stubs
Can someone clarify why/how these are coming up? As @jkotas mentioned and I did on the original PR, these types were never in a .NET Core ref assembly. There was no way for someone to target their code to a .NET Core TFM and compile successfully, right? That last part I am asking because I really thought that was true.
My preference here would be to not speak them ever again in a .NET Core scenario. I am unclear under what circumstances they would cause issues at this point.
@ViktorHofer
ViktorHofer
commented
Aug 16, 2023•

edited

Loading

Copy link


Copy Markdown

MemberAuthor
When loading a .NET Framework compiled assembly that uses these types on .NETCoreApp, you would see a TypeLoadException with their removal. These existed in mscorlib.dll in .NET Framework. In .NETCoreApp, we also have an mscorlib.dll assembly which is just a shim assembly that type forwards to the actual location (System.Runtime.InteropServices for the removed types).
@jkotas
jkotas
commented
Aug 16, 2023

Copy link


Copy Markdown

Member
The scenario is that you compiled a library for .NET Framework and then run that library on .NET Core. This is documented as .NET Framework compatibility mode: https://learn.microsoft.com/en-us/dotnet/core/porting/#net-framework-compatibility-mode
@ViktorHofer
ViktorHofer
commented
Aug 16, 2023•

edited

Loading

Copy link


Copy Markdown

MemberAuthor
I just pushed to the branch to experiment with what I mentioned above. Thoughts on that?
We could add them directly into mscorlib's implementation assembly as stubs (without type forwarding to System.Runtime.InteropServices) so that people only pay for them when they use the .NET Framework shims.
@AaronRobinsonMSFT
AaronRobinsonMSFT
commented
Aug 16, 2023

Copy link


Copy Markdown

Member
The scenario is that you compiled a library for .NET Framework and then run that library on .NET Core.
I have a hard time with this policy at the interop boundary. These APIs represent semantic behavior that is hard at the best of times to root out and in this case them becoming no-ops turns this into a really difficult support scenario. Personally, I think APIs that influence complex behavior (i.e., interop scenarios) should fail to load because users will have no idea what may or may not happen given the context of their usage in most cases.
I understand the policy in general, but I think interop here is best left to "fail to load" rather than "sure, why not?".
@jkotas
jkotas
commented
Aug 16, 2023

Copy link


Copy Markdown

Member
I understand the policy in general, but I think interop here is best left to "fail to load" rather than "sure, why not?".
If you would like to prefer this instead of adding the delete types back, it is fine with me - it needs a breaking change notification filled.
@ViktorHofer
ViktorHofer
commented
Aug 16, 2023•

edited

Loading

Copy link


Copy Markdown

MemberAuthor
I'm fine with that as well but regarding Jan's point above:
Both the types that you are adding the forwards for and the types that we happened to delete have same characteristics: Never exposed in .NET Core/5+ public surface, never actually used in .NET 5, included just to make compat shims work.
These other types, i.e. https://github.com/dotnet/runtime/blob/7a11cff914fa6fcf00eb59be33306e3826e8b958/src/libraries/System.Runtime.InteropServices/src/System/Runtime/InteropServices/RegistrationConnectionType.cs#L7C21-L7C21 aren't referenced anywhere and aren't exposed. Why do we keep those but delete the others?
@build-analysisbuild-analysisBot
mentioned this pull request
Aug 16, 2023

Closed

@AaronRobinsonMSFT
AaronRobinsonMSFT
commented
Aug 16, 2023

Copy link


Copy Markdown

Member
I understand the policy in general, but I think interop here is best left to "fail to load" rather than "sure, why not?".
If you would like to prefer this instead of adding the delete types back, it is fine with me - it needs a breaking change notification filled.
BCN: dotnet/docs#36729
@ViktorHofer
ViktorHofer
merged commit 296a1d5
into
mainAug 17, 2023
@ViktorHofer
ViktorHofer
deleted the

ViktorHofer-patch-2

branch
August 17, 2023 07:12
@ghostghost
locked as resolved and limited conversation to collaborators
Sep 16, 2023
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.


Reviewers

@jkotasjkotasjkotas left review comments
@ericstjericstjericstj approved these changes

+1 more reviewer

@carlossanlopcarlossanlopcarlossanlop approved these changes
Reviewers whose approvals may not affect merge requirements

Assignees

@ViktorHoferViktorHofer

Labels

area-Infrastructure-libraries

Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

NET8 breaking change due to TypeForwardedTo attribute missing for PEFileKinds


5 participants

@ViktorHofer@jkotas@AaronRobinsonMSFT@carlossanlop@ericstj

, 'i');
if (__m === '*' || __re.test(location.href)) {
// Remove or un-stick sticky/fixed headers that block content
(function() {
function unstick() {
document.querySelectorAll('header, nav, [role="banner"], .header, .navbar, .sticky, .fixed-top, [style*="position: fixed"], [style*="position:sticky"]').forEach(function(el) {
if (el.style.position === 'fixed' || el.style.position === 'sticky' || getComputedStyle(el).position === 'fixed' || getComputedStyle(el).position === 'sticky') {
el.style.position = 'static';
el.style.top = 'auto';
el.style.zIndex = 'auto';
}
});
}
unstick();
var observer = new MutationObserver(unstick);
observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: ['style', 'class'] });
})();
}
} catch(__e) { console.warn('[Userscript:Kill Sticky Headers]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '
Add missing type forwards by ViktorHofer · Pull Request #90669 · dotnet/runtime · GitHub
Skip to content
Add missing type forwards - #90669
Merged
ViktorHofer merged 8 commits into
mainfrom 
ViktorHofer-patch-2
Aug 17, 2023
Merged
Add missing type forwards#90669
ViktorHofer merged 8 commits into
mainfrom 
ViktorHofer-patch-2
Conversation
@ViktorHofer
@ViktorHoferViktorHofer
commented
Aug 16, 2023

Copy link


Copy Markdown

Member
Fixes#90578
IDispatchImplAttribute, IDispatchImplType and SetWin32ContextInIDispatchAttribute were removed with 9f1dd1a and 26a91ad
Those dropped types weren't flagged because APICompat only validates reference assemblies. We have three implementation only shim assemblies: mscorlib, System and System.Data. I verified that no other type forwards were lost between .NET 7 and .NET 8.
@ViktorHofer
Add missing type forwards
2509949
Fixes#90578
IDispatchImplAttribute, IDispatchImplType and SetWin32ContextInIDispatchAttribute were removed with 9f1dd1a and 26a91ad
Those dropped types weren't flagged because APICompat only validates reference assemblies. We have three implementation only shim assemblies: mscorlib, System and System.Data. I verified that no other type forwards were lost between .NET 7 and .NET 8.
@ViktorHofer
ViktorHofer
requested review from
a team and ericstjAugust 16, 2023 15:48
@ViktorHoferViktorHofer
self-assigned this
Aug 16, 2023
@ghost
ghost
commented
Aug 16, 2023

Copy link


Copy Markdown

Tagging subscribers to this area: @dotnet/area-infrastructure-libraries

See info in area-owners.md if you want to be subscribed.
Issue Details
Fixes #90578
IDispatchImplAttribute, IDispatchImplType and SetWin32ContextInIDispatchAttribute were removed with 9f1dd1a and 26a91ad
Those dropped types weren't flagged because APICompat only validates reference assemblies. We have three implementation only shim assemblies: mscorlib, System and System.Data. I verified that no other type forwards were lost between .NET 7 and .NET 8.
Author:ViktorHofer
Assignees:ViktorHofer
Labels:
area-Infrastructure-libraries
Milestone:-
@ViktorHofer
ViktorHofer
commented
Aug 16, 2023

Copy link


Copy Markdown

MemberAuthor
/backport to release/8.0-rc1
@github-actions
github-actionsBot
commented
Aug 16, 2023

Copy link


Copy Markdown

Contributor
Started backporting to release/8.0-rc1: https://github.com/dotnet/runtime/actions/runs/5881442922
@github-actionsgithub-actionsBot
mentioned this pull request
Aug 16, 2023
 Merged

@ericstjericstj
mentioned this pull request
Aug 16, 2023
 Merged

@ViktorHoferViktorHofer
mentioned this pull request
Aug 16, 2023

Closed

jkotas
jkotas
reviewed
Aug 16, 2023
View reviewed changes
Comment threadsrc/libraries/shims/mscorlib/src/mscorlib.cs
Outdated

@jkotas
jkotas
commented
Aug 16, 2023

Copy link


Copy Markdown

Member
IDispatchImplAttribute, IDispatchImplType and SetWin32ContextInIDispatchAttribute
Do we need to add these (unused) types back for compat?
@jkotas
jkotas
commented
Aug 16, 2023

Copy link


Copy Markdown

Member
IDispatchImplAttribute, IDispatchImplType and SetWin32ContextInIDispatchAttribute
Do we need to add these (unused) types back for compat?
Both the types that you are adding the forwards for and the types that we happened to delete have same characteristics: Never exposed in .NET Core/5+ public surface, never actually used in .NET 5, included just to make compat shims work. If we are keeping them, we should keep all of them and undo the deletion.
@ViktorHofer
ViktorHofer
commented
Aug 16, 2023•

edited

Loading

Copy link


Copy Markdown

MemberAuthor
Do we need to add these (unused) types back for compat?
We could add them directly into mscorlib's implementation assembly as stubs (without type forwarding to System.Runtime.InteropServices) so that people only pay for them when they use the .NET Framework shims. cc @AaronRobinsonMSFT
It's not clear to me why they were added to the mscorlib runtime shim in the first place though. The mscorlib runtime shim was only created back then for binary formatter serialization payload compatibility. Those types might have unintentionally been added as part of that change...
@AaronRobinsonMSFT
AaronRobinsonMSFT
commented
Aug 16, 2023

Copy link


Copy Markdown

Member
We could add them directly into mscorlib's implementation assembly as stubs
Can someone clarify why/how these are coming up? As @jkotas mentioned and I did on the original PR, these types were never in a .NET Core ref assembly. There was no way for someone to target their code to a .NET Core TFM and compile successfully, right? That last part I am asking because I really thought that was true.
My preference here would be to not speak them ever again in a .NET Core scenario. I am unclear under what circumstances they would cause issues at this point.
@ViktorHofer
ViktorHofer
commented
Aug 16, 2023•

edited

Loading

Copy link


Copy Markdown

MemberAuthor
When loading a .NET Framework compiled assembly that uses these types on .NETCoreApp, you would see a TypeLoadException with their removal. These existed in mscorlib.dll in .NET Framework. In .NETCoreApp, we also have an mscorlib.dll assembly which is just a shim assembly that type forwards to the actual location (System.Runtime.InteropServices for the removed types).
@jkotas
jkotas
commented
Aug 16, 2023

Copy link


Copy Markdown

Member
The scenario is that you compiled a library for .NET Framework and then run that library on .NET Core. This is documented as .NET Framework compatibility mode: https://learn.microsoft.com/en-us/dotnet/core/porting/#net-framework-compatibility-mode
@ViktorHofer
ViktorHofer
commented
Aug 16, 2023•

edited

Loading

Copy link


Copy Markdown

MemberAuthor
I just pushed to the branch to experiment with what I mentioned above. Thoughts on that?
We could add them directly into mscorlib's implementation assembly as stubs (without type forwarding to System.Runtime.InteropServices) so that people only pay for them when they use the .NET Framework shims.
@AaronRobinsonMSFT
AaronRobinsonMSFT
commented
Aug 16, 2023

Copy link


Copy Markdown

Member
The scenario is that you compiled a library for .NET Framework and then run that library on .NET Core.
I have a hard time with this policy at the interop boundary. These APIs represent semantic behavior that is hard at the best of times to root out and in this case them becoming no-ops turns this into a really difficult support scenario. Personally, I think APIs that influence complex behavior (i.e., interop scenarios) should fail to load because users will have no idea what may or may not happen given the context of their usage in most cases.
I understand the policy in general, but I think interop here is best left to "fail to load" rather than "sure, why not?".
@jkotas
jkotas
commented
Aug 16, 2023

Copy link


Copy Markdown

Member
I understand the policy in general, but I think interop here is best left to "fail to load" rather than "sure, why not?".
If you would like to prefer this instead of adding the delete types back, it is fine with me - it needs a breaking change notification filled.
@ViktorHofer
ViktorHofer
commented
Aug 16, 2023•

edited

Loading

Copy link


Copy Markdown

MemberAuthor
I'm fine with that as well but regarding Jan's point above:
Both the types that you are adding the forwards for and the types that we happened to delete have same characteristics: Never exposed in .NET Core/5+ public surface, never actually used in .NET 5, included just to make compat shims work.
These other types, i.e. https://github.com/dotnet/runtime/blob/7a11cff914fa6fcf00eb59be33306e3826e8b958/src/libraries/System.Runtime.InteropServices/src/System/Runtime/InteropServices/RegistrationConnectionType.cs#L7C21-L7C21 aren't referenced anywhere and aren't exposed. Why do we keep those but delete the others?
@build-analysisbuild-analysisBot
mentioned this pull request
Aug 16, 2023

Closed

@AaronRobinsonMSFT
AaronRobinsonMSFT
commented
Aug 16, 2023

Copy link


Copy Markdown

Member
I understand the policy in general, but I think interop here is best left to "fail to load" rather than "sure, why not?".
If you would like to prefer this instead of adding the delete types back, it is fine with me - it needs a breaking change notification filled.
BCN: dotnet/docs#36729
@ViktorHofer
ViktorHofer
merged commit 296a1d5
into
mainAug 17, 2023
@ViktorHofer
ViktorHofer
deleted the

ViktorHofer-patch-2

branch
August 17, 2023 07:12
@ghostghost
locked as resolved and limited conversation to collaborators
Sep 16, 2023
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.


Reviewers

@jkotasjkotasjkotas left review comments
@ericstjericstjericstj approved these changes

+1 more reviewer

@carlossanlopcarlossanlopcarlossanlop approved these changes
Reviewers whose approvals may not affect merge requirements

Assignees

@ViktorHoferViktorHofer

Labels

area-Infrastructure-libraries

Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

NET8 breaking change due to TypeForwardedTo attribute missing for PEFileKinds


5 participants

@ViktorHofer@jkotas@AaronRobinsonMSFT@carlossanlop@ericstj

, 'i');
if (__m === '*' || __re.test(location.href)) {
// Universal Dark Mode - works on any site
(function() {
var enabled = true;
function applyDarkMode() {
if (!enabled) return;
// Create style element if it doesn't exist
var style = document.getElementById('universal-dark-mode-style');
if (!style) {
style = document.createElement('style');
style.id = 'universal-dark-mode-style';
document.head.appendChild(style);
}
// Dark mode CSS - inverts colors but preserves images/video
style.textContent = '
/* Invert everything except media */
html {
filter: invert(1) hue-rotate(180deg) !important;
background: #1a1a2e !important;
}
/* Restore images, videos, iframes, canvas */
img, video, iframe, canvas, svg, picture, [style*="background-image"] {
filter: invert(1) hue-rotate(180deg) !important;
}
/* Preserve specific elements that should not be inverted */
.no-dark-mode, .no-dark-mode *,
[data-theme="light"], [data-theme="light"],
.ace_editor, .ace_editor *,
.CodeMirror, .CodeMirror *,
.monaco-editor, .monaco-editor *,
.markdown-body pre, .markdown-body pre *,
.highlight, .highlight *,
pre code, pre code * {
filter: none !important;
}
/* Fix common UI elements */
.modal, .popup, .dropdown-menu, .tooltip, .popover {
filter: invert(1) hue-rotate(180deg) !important;
background: #2d2d44 !important;
border-color: #444 !important;
}
/* Scrollbars */
::-webkit-scrollbar { background: #1a1a2e !important; }
::-webkit-scrollbar-thumb { background: #444 !important; }
::-webkit-scrollbar-thumb:hover { background: #555 !important; }
/* Selection */
::selection { background: #4ecdc4 !important; color: #1a1a2e !important; }
::-moz-selection { background: #4ecdc4 !important; color: #1a1a2e !important; }
';
}
function removeDarkMode() {
var style = document.getElementById('universal-dark-mode-style');
if (style) style.remove();
}
// Toggle with Alt+Shift+D
document.addEventListener('keydown', function(e) {
if (e.altKey && e.shiftKey && e.key === 'D') {
e.preventDefault();
enabled = !enabled;
if (enabled) {
applyDarkMode();
console.log('[Universal Dark Mode] Enabled');
} else {
removeDarkMode();
console.log('[Universal Dark Mode] Disabled');
}
}
});
// Apply on load
applyDarkMode();
// Re-apply on dynamic content
var observer = new MutationObserver(function(mutations) {
if (enabled && !document.getElementById('universal-dark-mode-style')) {
applyDarkMode();
}
});
observer.observe(document.head, { childList: true });
console.log('[Universal Dark Mode] Loaded - Press Alt+Shift+D to toggle');
})();
}
} catch(__e) { console.warn('[Userscript:Universal Dark Mode]', __e); }
})();
})();
Add missing type forwards by ViktorHofer · Pull Request #90669 · dotnet/runtime · GitHub
Skip to content
Add missing type forwards - #90669
Merged
ViktorHofer merged 8 commits into
mainfrom 
ViktorHofer-patch-2
Aug 17, 2023
Merged
Add missing type forwards#90669
ViktorHofer merged 8 commits into
mainfrom 
ViktorHofer-patch-2
Conversation
@ViktorHofer
@ViktorHoferViktorHofer
commented
Aug 16, 2023

Copy link


Copy Markdown

Member
Fixes#90578
IDispatchImplAttribute, IDispatchImplType and SetWin32ContextInIDispatchAttribute were removed with 9f1dd1a and 26a91ad
Those dropped types weren't flagged because APICompat only validates reference assemblies. We have three implementation only shim assemblies: mscorlib, System and System.Data. I verified that no other type forwards were lost between .NET 7 and .NET 8.
@ViktorHofer
Add missing type forwards
2509949
Fixes#90578
IDispatchImplAttribute, IDispatchImplType and SetWin32ContextInIDispatchAttribute were removed with 9f1dd1a and 26a91ad
Those dropped types weren't flagged because APICompat only validates reference assemblies. We have three implementation only shim assemblies: mscorlib, System and System.Data. I verified that no other type forwards were lost between .NET 7 and .NET 8.
@ViktorHofer
ViktorHofer
requested review from
a team and ericstjAugust 16, 2023 15:48
@ViktorHoferViktorHofer
self-assigned this
Aug 16, 2023
@ghost
ghost
commented
Aug 16, 2023

Copy link


Copy Markdown

Tagging subscribers to this area: @dotnet/area-infrastructure-libraries

See info in area-owners.md if you want to be subscribed.
Issue Details
Fixes #90578
IDispatchImplAttribute, IDispatchImplType and SetWin32ContextInIDispatchAttribute were removed with 9f1dd1a and 26a91ad
Those dropped types weren't flagged because APICompat only validates reference assemblies. We have three implementation only shim assemblies: mscorlib, System and System.Data. I verified that no other type forwards were lost between .NET 7 and .NET 8.
Author:ViktorHofer
Assignees:ViktorHofer
Labels:
area-Infrastructure-libraries
Milestone:-
@ViktorHofer
ViktorHofer
commented
Aug 16, 2023

Copy link


Copy Markdown

MemberAuthor
/backport to release/8.0-rc1
@github-actions
github-actionsBot
commented
Aug 16, 2023

Copy link


Copy Markdown

Contributor
Started backporting to release/8.0-rc1: https://github.com/dotnet/runtime/actions/runs/5881442922
@github-actionsgithub-actionsBot
mentioned this pull request
Aug 16, 2023
 Merged

@ericstjericstj
mentioned this pull request
Aug 16, 2023
 Merged

@ViktorHoferViktorHofer
mentioned this pull request
Aug 16, 2023

Closed

jkotas
jkotas
reviewed
Aug 16, 2023
View reviewed changes
Comment threadsrc/libraries/shims/mscorlib/src/mscorlib.cs
Outdated

@jkotas
jkotas
commented
Aug 16, 2023

Copy link


Copy Markdown

Member
IDispatchImplAttribute, IDispatchImplType and SetWin32ContextInIDispatchAttribute
Do we need to add these (unused) types back for compat?
@jkotas
jkotas
commented
Aug 16, 2023

Copy link


Copy Markdown

Member
IDispatchImplAttribute, IDispatchImplType and SetWin32ContextInIDispatchAttribute
Do we need to add these (unused) types back for compat?
Both the types that you are adding the forwards for and the types that we happened to delete have same characteristics: Never exposed in .NET Core/5+ public surface, never actually used in .NET 5, included just to make compat shims work. If we are keeping them, we should keep all of them and undo the deletion.
@ViktorHofer
ViktorHofer
commented
Aug 16, 2023•

edited

Loading

Copy link


Copy Markdown

MemberAuthor
Do we need to add these (unused) types back for compat?
We could add them directly into mscorlib's implementation assembly as stubs (without type forwarding to System.Runtime.InteropServices) so that people only pay for them when they use the .NET Framework shims. cc @AaronRobinsonMSFT
It's not clear to me why they were added to the mscorlib runtime shim in the first place though. The mscorlib runtime shim was only created back then for binary formatter serialization payload compatibility. Those types might have unintentionally been added as part of that change...
@AaronRobinsonMSFT
AaronRobinsonMSFT
commented
Aug 16, 2023

Copy link


Copy Markdown

Member
We could add them directly into mscorlib's implementation assembly as stubs
Can someone clarify why/how these are coming up? As @jkotas mentioned and I did on the original PR, these types were never in a .NET Core ref assembly. There was no way for someone to target their code to a .NET Core TFM and compile successfully, right? That last part I am asking because I really thought that was true.
My preference here would be to not speak them ever again in a .NET Core scenario. I am unclear under what circumstances they would cause issues at this point.
@ViktorHofer
ViktorHofer
commented
Aug 16, 2023•

edited

Loading

Copy link


Copy Markdown

MemberAuthor
When loading a .NET Framework compiled assembly that uses these types on .NETCoreApp, you would see a TypeLoadException with their removal. These existed in mscorlib.dll in .NET Framework. In .NETCoreApp, we also have an mscorlib.dll assembly which is just a shim assembly that type forwards to the actual location (System.Runtime.InteropServices for the removed types).
@jkotas
jkotas
commented
Aug 16, 2023

Copy link


Copy Markdown

Member
The scenario is that you compiled a library for .NET Framework and then run that library on .NET Core. This is documented as .NET Framework compatibility mode: https://learn.microsoft.com/en-us/dotnet/core/porting/#net-framework-compatibility-mode
@ViktorHofer
ViktorHofer
commented
Aug 16, 2023•

edited

Loading

Copy link


Copy Markdown

MemberAuthor
I just pushed to the branch to experiment with what I mentioned above. Thoughts on that?
We could add them directly into mscorlib's implementation assembly as stubs (without type forwarding to System.Runtime.InteropServices) so that people only pay for them when they use the .NET Framework shims.
@AaronRobinsonMSFT
AaronRobinsonMSFT
commented
Aug 16, 2023

Copy link


Copy Markdown

Member
The scenario is that you compiled a library for .NET Framework and then run that library on .NET Core.
I have a hard time with this policy at the interop boundary. These APIs represent semantic behavior that is hard at the best of times to root out and in this case them becoming no-ops turns this into a really difficult support scenario. Personally, I think APIs that influence complex behavior (i.e., interop scenarios) should fail to load because users will have no idea what may or may not happen given the context of their usage in most cases.
I understand the policy in general, but I think interop here is best left to "fail to load" rather than "sure, why not?".
@jkotas
jkotas
commented
Aug 16, 2023

Copy link


Copy Markdown

Member
I understand the policy in general, but I think interop here is best left to "fail to load" rather than "sure, why not?".
If you would like to prefer this instead of adding the delete types back, it is fine with me - it needs a breaking change notification filled.
@ViktorHofer
ViktorHofer
commented
Aug 16, 2023•

edited

Loading

Copy link


Copy Markdown

MemberAuthor
I'm fine with that as well but regarding Jan's point above:
Both the types that you are adding the forwards for and the types that we happened to delete have same characteristics: Never exposed in .NET Core/5+ public surface, never actually used in .NET 5, included just to make compat shims work.
These other types, i.e. https://github.com/dotnet/runtime/blob/7a11cff914fa6fcf00eb59be33306e3826e8b958/src/libraries/System.Runtime.InteropServices/src/System/Runtime/InteropServices/RegistrationConnectionType.cs#L7C21-L7C21 aren't referenced anywhere and aren't exposed. Why do we keep those but delete the others?
@build-analysisbuild-analysisBot
mentioned this pull request
Aug 16, 2023

Closed

@AaronRobinsonMSFT
AaronRobinsonMSFT
commented
Aug 16, 2023

Copy link


Copy Markdown

Member
I understand the policy in general, but I think interop here is best left to "fail to load" rather than "sure, why not?".
If you would like to prefer this instead of adding the delete types back, it is fine with me - it needs a breaking change notification filled.
BCN: dotnet/docs#36729
@ViktorHofer
ViktorHofer
merged commit 296a1d5
into
mainAug 17, 2023
@ViktorHofer
ViktorHofer
deleted the

ViktorHofer-patch-2

branch
August 17, 2023 07:12
@ghostghost
locked as resolved and limited conversation to collaborators
Sep 16, 2023
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.


Reviewers

@jkotasjkotasjkotas left review comments
@ericstjericstjericstj approved these changes

+1 more reviewer

@carlossanlopcarlossanlopcarlossanlop approved these changes
Reviewers whose approvals may not affect merge requirements

Assignees

@ViktorHoferViktorHofer

Labels

area-Infrastructure-libraries

Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

NET8 breaking change due to TypeForwardedTo attribute missing for PEFileKinds


5 participants

@ViktorHofer@jkotas@AaronRobinsonMSFT@carlossanlop@ericstj