search

testcontainers / testcontainers-dotnet

A library to support tests with throwaway instances of Docker containers for all compatible .NET Standard versions.
https://dotnet.testcontainers.org
MIT License
3.65k stars 250 forks source link

[Bug]: System.MissingMethodException after upgrade from 3.6.0 to 3.7.0 #1096

Closed StefH closed 5 months ago

StefH commented 5 months ago

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:

HofmeisterAn commented 5 months ago

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.

StefH commented 5 months ago

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 https://github.com/WireMock-Net/WireMock.Net/issues/1059 this is indeed described by the user : Testcontainers.CosmosDb version 3.7.0 is used.

StefH commented 5 months ago

@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?

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?

HofmeisterAn commented 5 months ago

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.

StefH commented 5 months ago

What about the other issue?

I don't know yet, I'm waiting on the user to respond... I'll keep you updated.

StefH commented 5 months ago

@HofmeisterAn I just got confirmation that it is indeed related to 3.7.0 (https://github.com/WireMock-Net/WireMock.Net/issues/1054#issuecomment-1909605082)

So for now I'll pin the version in WireMock.Net to [3.7.0].

HofmeisterAn commented 5 months ago

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.

HofmeisterAn commented 5 months ago

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.

StefH commented 5 months ago

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.

StefH commented 5 months ago

FYI: a new NuGet from WireMock.Net has been released which pins the version from testcontainers to 3.7.0

HofmeisterAn commented 5 months ago

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.