Restore ability on .NET 9 and later to save dynamic assemblies to disk #718
+367
−45
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Member
Author
|
@jonorossi, do you think the ability to save dynamic assemblies should be publicly exposed, or should it remain an internal development-only feature? I am undecided whether the feature makes sense in general, given that there is no way to load the saved assemblies back into DynamicProxy's type cache. (That would require de-serialization using |
stakx
commented
Dec 31, 2025
src/Castle.Core.Tests/DynamicProxy.Tests/PersistentProxyBuilderTestCase.cs
Outdated
Show resolved
Hide resolved
src/Castle.Core.Tests/DynamicProxy.Tests/PersistentProxyBuilderTestCase.cs
Outdated
Show resolved
Hide resolved
src/Castle.Core.Tests/DynamicProxy.Tests/PersistentProxyBuilderTestCase.cs
Outdated
Show resolved
Hide resolved
Comment on lines
+57
to
+56
| // for testing purposes | ||
| internal event Action<string>? AssemblySaved; |
Member
Author
There was a problem hiding this comment.
I don't particularly like adding such stuff only for internal testing. Perhaps it would be worth thinking about doing this in a way that would make sense for public use, too?
Merged
Note that `catch`-ing strong-naming failures in all cases isn't just a refactoring, but a functional change. It seems appropriate, and more correct than what we had before, becaus creating a dynamic assembly and strong-naming it are really separate concerns.
There is the potential of file collisions when several `PersistentProxy- Builder`s are used concurrently. Better use a random name fragment in- stead of a steadily increasing generation count.
stakx
force-pushed
the
persistent-proxy-builder
branch
from
19dc40b to
209108c
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR adds a
PersistentProxyBuilderimplementation for .NET 9+ – similar, but not identical, to the one we already have for the .NET Framework. The minimum platform requirement for this new implementation is .NET 9 because it is based on SRE'sPersistedAssemblyBuilder, which was introduced in that version of the runtime. Therefore I am also adding thenet9.0TFM to the library.I have an immediate need for this as an aid in improving by-ref-like types support further (#663), which is quite difficult when one cannot inspect the generated assemblies directly. While the proposed implementation should suffice for that specific purpose, it isn't thoroughly tested yet and it comes with certain caveats (as noted in its XML documentation comment). However, since it is an opt-in feature, it seems reasonably safe to me to publicly expose it.
What is left to be done at a later time is setting up IL verification during test execution on .NET 9 and later, even though that now seems to be within reach.
Closes #697.