Jose

We decide not to add this new method, and to improve loadSlice see #4733

> How do we handle the following (did it work before and does it work now): In 3.7 we have `--all` which instruct IcePy to also generate code for included...

I think this is a problem with dotnet format not correctly loading the projects, let's see if we get a reply from https://github.com/dotnet/sdk/issues/51529

The attached crash log shows this: ``` Thread 16 Crashed: 0 TestDriver 0x10052f628 std::__1::__hash_table::remove(std::__1::__hash_const_iterator) + 104 (__hash_table:1883) 1 TestDriver 0x10052f554 std::__1::__hash_table::erase(std::__1::__hash_const_iterator) + 88 (__hash_table:1832) 2 TestDriver 0x10052b89c std::__1::unordered_map::erase[abi:ne190102](std::__1::__hash_map_iterator) + 56...

Seems like a duplicate of https://github.com/zeroc-ice/ice/issues/3229

https://github.com/zeroc-ice/ice/blob/614281c5621d7b43cf882b1e3f6110853e488592/swift/src/IceImpl/LocalObject.mm#L8-L9 I don't understand this comment, if the map only holds weak references why would it trigger object destruction?

Moved to 3.8.1, we should consider update the code as @externl suggested above in https://github.com/zeroc-ice/ice/issues/4143#issuecomment-3491461443

Not clear that we should use `getPropertiesForPrefix` here, this method is just getting the SSL certs default dir, the default host, and the IPv6 settings. We don't want to accidentally...

The client log shows and exception sending the datagram lookup requets ``` -- 10/17/2024 15:04:03:894 client: Lookup: retrying locator lookup: lookup = IceLocatorDiscovery/Lookup -d -e 1.1:udp -h 239.255.0.1 -p 14299...

It seems like the server connection is already closed when we accept the next stream: `ValueTask nextAcceptStreamTask = sut.Server.AcceptStreamAsync(default);` I don't see other way this code could return a completed...