Re-merge DirectWriteForwarder into PresentationCore #1727
Conversation
… building a static lib.
…build object files.
Author: Rob LaDuca <[email protected]>
- Some file re-arrangement - Adding over-arching merge project - Updating PCoreCSharp to use PCoreCPP Author: Rob LaDuca <[email protected]>
Disabling some ancillary things to focus on getting the assembly linking.
…embly info generation for interstital PCore assemblies.
… merged assembly to get appropriate assembly info.
…re can access them without the need for a resources DLL.
…should not have the CSharp moniker).
…use PresentationCore types.
ghost
requested review from
|
Can we just retain the name DrectWriteForwarder and not go back to the old nomenclature of PresentationCoreCpp etc.? |
src/Microsoft.DotNet.Wpf/src/PresentationCore/CSharp/PresentationCoreCSharp.csproj
Outdated
Show resolved
Hide resolved
src/Microsoft.DotNet.Wpf/src/PresentationCore/CSharp/PresentationCoreCSharp.csproj
Show resolved
Hide resolved
|
DirectWriteForwarder\main.cpp: We should validate under a debugger that this stuff really works. |
|
|
||
| <ItemGroup> |
There was a problem hiding this comment.
PBT was failing in various ways and, at the time, it was easier to move these to base than to figure that piece out since it was functionally equivalent at runtime.
Since we have confidence in the rest of the build at this point, I can take another look at this and see if I can puzzle out what was causing issues in PBT. It's possible that they don't even occur anymore after some of the other commits.
There was a problem hiding this comment.
What we are getting is:
..\WindowsBase\Fonts\GlobalMonospace.CompositeFont : fatal error LNK1107: invalid or corrupt file: cannot read at 0x65B8 [d:\repos\wpf_github\src\Microsoft.DotNet.Wpf\src\ PresentationCore\PresentationCore.vcxproj]
It looks like adding the Resource here is making the linker attempt to link this into the final assembly. One reason for this might be we don't actually have a compile pass for the merge project. It's only the linker. The resources aren't carried forward apart from what the metadatamerge does, which doesn't include resources (as is evidenced by the PCoreCSharp resources not being merged automatically).
There was a problem hiding this comment.
I tried various ways of getting this in as a straight embedded resource, but I haven't been able to do so. This is the same set of issues that caused me to create PresentationCore-CommonResources in the first place. I'd rather not do this again and putting these into WindowsBase seems like the better fix.
There was a problem hiding this comment.
I just remembered why you can't do this - PBT doesn't support C++/CLI.
PBT definitely doesn't support codegen for anything besides VB and C#.
I don't remember now whether we can get resource embedding to work for C++/CLI (i.e., .vcxproj) projects.
You should just do what you were doing. Sorry about randomizing you.
There was a problem hiding this comment.
WinFx.targets understands knows how to hook correctly into C#/VB targets - those same hooks may not work correctly when building C++/CLI projects.
There was a problem hiding this comment.
Yeah all good, it made sense to look at this again because I know I just leap-frogged it when I hit it. But that all makes sense wrt to C++/CLI.
Yeah that's not a bad idea. PCoreCPP isn't a very good name, I'll swap it back. |
I already checked in WinDbg. Just did an "sxe ld dwrite" and checked that the stack runs through the PresentationCore module initializer, etc. All seemed good to me. |
…ectWriteForwarder isn't improperly referenced in the engineering system.
|
Fix comment: |
|
I see the AvTraceMessages.txt file in your PR. It says the the file was renamed without changes, so it looks like is wasn't deleted? It's no longer used, that part of codegen was converted to AvTraceMessages.xml. |
src/Microsoft.DotNet.Wpf/src/PresentationCore/CSharp/MS/internal/FontCache/FontSource.cs
Show resolved
Hide resolved
...osoft.DotNet.Wpf/src/Themes/PresentationFramework.Royale/PresentationFramework.Royale.csproj
Outdated
Show resolved
Hide resolved
That had just been sitting around, so I kept it from wherever it lived. If it's definitely no longer needed I can delete it. |
Yeah it isn't needed anymore. |
|
Do we need the module initializer for DirectWriteForwarder anymore? If I remember correctly, that was only needed because we had split from netmodule? |
Yes, the module initializer has always been there in DIrectWriteForwarder. What we added was one in PresentationCore to call through to the DirectWriteForwarder one. Now PresentationCore returns to status quo w.r.t. to module initialization. No more clunky il round tripping. |
Sorry, yeah I meant the one in PresentationCore! I don't see any of those files changed, unless I'm missing them? |
PresentationCore has always had a module initializer. When I say this, I mean back in .NET Framework. The module initializer comes from the CPP portion (now called DirectWriteForwarder) since C++/CLI has direct support for a DLL entry function that becomes an initializer. When this was split, we added back an initializer in PresentationCore (that was now fully C#) via IL modification (as C# does not support module initialization directly) so as to call through to DirectWriteForwarder and preserve initialization order. Since we're going back to the old way of doing things, the IL(D)Asm technique is gone, and we just get the module initializer for free from the merged C++/CLI portion (DirectWriteForwarder). So, still have one, still need one, just doing it the way it was done historically prior to the split. |
|
We have a better pathway to fix this, closing. See #1744 |
|
Thanks anyways for doing this in the open, I appreciate having an example of how to build and merge netmodules, this is pretty underdocumented. I've had to do this in the past and it was a lot of trial and error and I don't think I ever got it entirely right. I'm preserving the branch for future reference, if thats ok with you. |
Preserving it is completely fine. Just to make sure you realize, currently the private C++/CLI tools we use are necessary to build this merged module. Otherwise you will hit a linker error during metadata merging of the individual modules. These changes will eventually make their way to preview/public versions of VS, but they are not there just yet. There are other uses for this as well within the WPF build and we may yet come back to some version of this to accomplish other things. If you have any questions about parts of this, feel free to ask! |
ghost
locked as resolved and limited conversation to collaborators
Addresses #1549
Reverting to using a NetModule and merging with a C++/CLI object file in order to build the C++/CLI and C# components of PresentationCore into a single module.
Tested:
In Progress: