[Bug]: System.MissingMethodException after upgrade from 3.6.0 to 3.7.0
StefH opened this issue · comments
Testcontainers version
3.7.0
Using the latest Testcontainers version?
Yes
Host OS
Windows
Host arch
x86
.NET version
8
Docker version
Client:
Cloud integration: v1.0.35+desktop.5
Version: 24.0.7
API version: 1.43
Go version: go1.20.10
Git commit: afdd53b
Built: Thu Oct 26 09:08:44 2023
OS/Arch: windows/amd64
Context: default
Server: Docker Desktop 4.26.1 (131620)
Engine:
Version: 24.0.7
API version: 1.43 (minimum version 1.12)
Go version: go1.20.10
Git commit: 311b9ff
Built: Thu Oct 26 09:08:02 2023
OS/Arch: linux/amd64
Experimental: false
containerd:
Version: 1.6.25
GitCommit: d8f198a4ed8892c764191ef7b3b06d8a2eeb5c7f
runc:
Version: 1.1.10
GitCommit: v1.1.10-0-g18a0cb0
docker-init:
Version: 0.19.0
GitCommit: de40ad0
Docker info
Client:
Version: 24.0.7
Context: default
Debug Mode: false
Plugins:
buildx: Docker Buildx (Docker Inc.)
Version: v0.12.0-desktop.2
Path: C:\Program Files\Docker\cli-plugins\docker-buildx.exe
compose: Docker Compose (Docker Inc.)
Version: v2.23.3-desktop.2
Path: C:\Program Files\Docker\cli-plugins\docker-compose.exe
dev: Docker Dev Environments (Docker Inc.)
Version: v0.1.0
Path: C:\Program Files\Docker\cli-plugins\docker-dev.exe
extension: Manages Docker extensions (Docker Inc.)
Version: v0.2.21
Path: C:\Program Files\Docker\cli-plugins\docker-extension.exe
feedback: Provide feedback, right in your terminal! (Docker Inc.)
Version: 0.1
Path: C:\Program Files\Docker\cli-plugins\docker-feedback.exe
init: Creates Docker-related starter files for your project (Docker Inc.)
Version: v0.1.0-beta.10
Path: C:\Program Files\Docker\cli-plugins\docker-init.exe
sbom: View the packaged-based Software Bill Of Materials (SBOM) for an image (Anchore Inc.)
Version: 0.6.0
Path: C:\Program Files\Docker\cli-plugins\docker-sbom.exe
scan: Docker Scan (Docker Inc.)
Version: v0.26.0
Path: C:\Program Files\Docker\cli-plugins\docker-scan.exe
scout: Docker Scout (Docker Inc.)
Version: v1.2.0
Path: C:\Program Files\Docker\cli-plugins\docker-scout.exe
Server:
Containers: 5
Running: 4
Paused: 0
Stopped: 1
Images: 20
Server Version: 24.0.7
Storage Driver: overlay2
Backing Filesystem: extfs
Supports d_type: true
Using metacopy: false
Native Overlay Diff: true
userxattr: false
Logging Driver: json-file
Cgroup Driver: cgroupfs
Cgroup Version: 1
Plugins:
Volume: local
Network: bridge host ipvlan macvlan null overlay
Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
Swarm: inactive
Runtimes: runc io.containerd.runc.v2
Default Runtime: runc
Init Binary: docker-init
containerd version: d8f198a4ed8892c764191ef7b3b06d8a2eeb5c7f
runc version: v1.1.10-0-g18a0cb0
init version: de40ad0
Security Options:
seccomp
Profile: unconfined
Kernel Version: 5.15.133.1-microsoft-standard-WSL2
Operating System: Docker Desktop
OSType: linux
Architecture: x86_64
CPUs: 8
Total Memory: 7.648GiB
Name: docker-desktop
ID: d0d60003-1f7b-4995-9aed-021a9ff0b4ea
Docker Root Dir: /var/lib/docker
Debug Mode: false
HTTP Proxy: http.docker.internal:3128
HTTPS Proxy: http.docker.internal:3128
No Proxy: hubproxy.docker.internal
Experimental: false
Insecure Registries:
hubproxy.docker.internal:5555
127.0.0.0/8
Live Restore Enabled: false
WARNING: No blkio throttle.read_bps_device support
WARNING: No blkio throttle.write_bps_device support
WARNING: No blkio throttle.read_iops_device support
WARNING: No blkio throttle.write_iops_device support
WARNING: daemon is not using the default seccomp profile
What happened?
System.MissingMethodException when upgrading from 3.6.0 to 3.7.0
Was there a breaking change in 3.7.0 or when using .NET 8 ?
Relevant log output
Exceptions:
System.MissingMethodException
Method not found: 'Void DotNet.Testcontainers.Configurations.ContainerConfiguration..ctor(DotNet.Testcontainers.Images.IImage, System.Func`2<Docker.DotNet.Models.ImageInspectResponse,Boolean>, System.String, System.String, System.String, System.String, System.Collections.Generic.IEnumerable`1<System.String>, System.Collections.Generic.IEnumerable`1<System.String>, System.Collections.Generic.IReadOnlyDictionary`2<System.String,System.String>, System.Collections.Generic.IReadOnlyDictionary`2<System.String,System.String>, System.Collections.Generic.IReadOnlyDictionary`2<System.String,System.String>, System.Collections.Generic.IReadOnlyDictionary`2<System.String,DotNet.Testcontainers.Configurations.IResourceMapping>, System.Collections.Generic.IEnumerable`1<DotNet.Testcontainers.Containers.IContainer>, System.Collections.Generic.IEnumerable`1<DotNet.Testcontainers.Configurations.IMount>, System.Collections.Generic.IEnumerable`1<DotNet.Testcontainers.Networks.INetwork>, System.Collections.Generic.IEnumerable`1<System.String>, System.Collections.Generic.IEnumerable`1<System.String>, DotNet.Testcontainers.Configurations.IOutputConsumer, System.Collections.Generic.IEnumerable`1<DotNet.Testcontainers.Configurations.IWaitUntil>, System.Func`3<DotNet.Testcontainers.Containers.IContainer,System.Threading.CancellationToken,System.Threading.Tasks.Task>, System.Nullable`1<Boolean>, System.Nullable`1<Boolean>)'.
at WireMock.Net.Testcontainers.WireMockConfiguration..ctor(String username, String password)
at WireMock.Net.Testcontainers.WireMockContainerBuilder..ctor()
at ../TestFactory.cs:line 22
at System.RuntimeMethodHandle.InvokeMethod(Object target, Void** arguments, Signature sig, Boolean isConstructor)
at System.Reflection.MethodBaseInvoker.InvokeWithNoArgs(Object obj, BindingFlags invokeAttr)
Unhandled exception. System.MissingMethodException: Method not found: 'Void DotNet.Testcontainers.Configurations.ContainerConfiguration..ctor(DotNet.Testcontainers.Images.IImage, System.Func`2<Dock
at WireMock.Net.Testcontainers.WireMockConfiguration..ctor(String username, String password)
at WireMock.Net.Testcontainers.WireMockContainerBuilder..ctor()
Additional information
Related bugs reported:
I think version 1.5.46 of WireMock.Net.Testcontainers is not compatible with Testcontainers version 3.7.0. The constructor for ContainerConfiguration
has changed slightly. I am sorry for this breaking change; while we internally forward and pass the correct data type to the configuration, I did not consider this specific scenario. Under normal usage (not mixing versions), this issue will not happen. This explains #1059. However, I am uncertain if the same situation applies to the other issue. Is it possible that the user is utilizing WireMock.Net.Testcontainers with a newer version of Testcontainers than the one used by the WireMock package?
It is probably a good idea to pin the Testcontainers version for upcoming WireMock releases. You will likely run into similar issues with version 3.8.0, which introduces the reuse feature that extends the configuration constructor as well.
Is it possible that the user is utilizing WireMock.Net.Testcontainers with a newer version of Testcontainers than the one used by the WireMock package?
Yes, in issue WireMock-Net/WireMock.Net#1059 this is indeed described by the user : Testcontainers.CosmosDb version 3.7.0 is used.
@HofmeisterAn
Thanks for looking into this issue, it's really appreciated.
I've some follow-up questions on this topic:
1]
Is it allowed (according to your design) to inherit from the ContainerConfiguration class?
- If it's not allowed or intended, define the class as sealed?
- If if is allowed, then no breaking changes should be introduced?
2]
Pinning the version to 3.7.0 will work fine when no other Testcontainer is used except for WireMock.Net, if another is used and that one is using version 3.6.0 (and only 3.6.0 exists) then there is again NuGet version conflict.
3]
If you expect breaking changes configuration constructor in the next version; isn't there a way to keep the existing constructor the same?
Yes, in issue WireMock-Net/WireMock.Net#1059 this is indeed described by the user : Testcontainers.CosmosDb version 3.7.0 is used.
What about the other issue?
Is it allowed (according to your design) to inherit from the ContainerConfiguration class?
Yes, it is allowed. We are doing it as well.
If if is allowed, then no breaking changes should be introduced?
It is not really a breaking change. There is nothing to do or to consider when switching from version 3.6.0 to 3.7.0. In your case, users are mixing (overwriting) versions that may not be (are) compatible with each other. This can also happen with other (transitive) dependencies. WireMock can specify compatible version ranges. Maybe we can do the same for all modules, requiring the same Testcontainers base version per module (then you do not need to do it). But I need to look into this first.
If you expect breaking changes configuration constructor in the next version; isn't there a way to keep the existing constructor the same?
Usually, we try to avoid breaking changes as much as we can. If it is not possible, we mention it in the release notes, but in this case, I do not really count it as a breaking change. Otherwise, we wouldn't be able to properly ship new versions. Mixing versions was never intended. But I can understand that the situation is not really great. I hope we can pin our modules to the base version. Then this issue should not happen again.
What about the other issue?
I don't know yet, I'm waiting on the user to respond... I'll keep you updated.
@HofmeisterAn
I just got confirmation that it is indeed related to 3.7.0 (WireMock-Net/WireMock.Net#1054 (comment))
So for now I'll pin the version in WireMock.Net to [3.7.0]
.
I kept thinking about this issue and did not come up with another solution. If you have any other ideas, I am happy to discuss them. However, since the users overwrite the dependency with a new version, I do not know what else I/we should do.
So for now I'll pin the version in WireMock.Net to
[3.7.0]
.
It would be interesting if we can do the same for the ProjectReference
.
I kept thinking about this issue and did not come up with another solution. If you have any other ideas, I am happy to discuss them. However, since the users overwrite the dependency with a new version, I do not know what else I/we should do.
Normally, users are allowed to use a newer version. This is also the case when I want to use a newer version from a Microsoft dependency.
I think it all relates to the fact that the public interfaces/classes should be backwards compatible. If this rule is applied, using an higher version should be possible.
FYI: a new NuGet from WireMock.Net has been released which pins the version from testcontainers to 3.7.0
I did some research, but unfortunately, I have not found a lot of useful information except that pinning project references is not supported right now. There is a "hacky" workaround which I have not looked into closely. I will close this issue because I have no plans to add the workaround. In case you find other information or want to continue discussing this issue and behavior, do not hesitate to reopen the issue. Thanks for the awareness and creating the issue.