-
-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make using of ImTools concurrently with DryIoc #30
Comments
Thanks for the open issue. What is your setup?
|
DLL for both packages.
This is the problem: cannot reference it as the compiler gets confused as both assemblies contains the same namespace.
I did not, but checking out the nuspec file it will still include all the external lib sources and would cause the conflict. To be complete, the same happens with FastExpressionCompiler as well. In that case, we had to change the namespace locally to be able to use it separately from DryIoc. Would be the solution for ImTools as well, but I don't wanna go this way because source inclusion...
|
DryIoc.Internal makes all public types internal including the types from FEC and ImTools. Thinking about this Today and I see two ideal choices:
Cons:
Cons:
@detoxhby What are your thoughts? |
Thanks for the ideas, I will think about the options how to solves this in a balanced manner! In the meantime, what about my original idea? In the external libs (FEC, IT), introducing a preprocessor For example: namespace ImTools
#if IMTOOLS_EMBEDDED
.Embedded
#endif
{
... Pros:
Cons:
No easy way to deal with the con other than jumping at least a minor version. |
You mean Then I think it is a good thing to go when thinking in the smaller steps. Thanks for the idea. |
Yes!
I have some serious deadlines currently for the next few weeks, but after that, I would gladly help with this work throughout all the projects (FEC, IT, DryIoc). How do you want to handle cross-project refences to coordinate this change? (FEC+IT first with minor version change and release THEN DryIoc with these new versions?) |
Maybe I have time to look next week. |
✔️ Alright, this is not a rush, take the time necessary for a correct major version change! Feel free to contact me if you need more information or a second-eye with ideas or realization details. |
Maybe a crazy thought, but why not make ImTools independent, and simply have Dryloc reference ImTools? That way, if projects reference both, there won't be any problem anymore, as there'll be only one shared library for the ImTools classes. |
I've answered to this with the second choice in the discussion above. @detoxhby |
Apologies, I thought I read the whole discussion, must've missed it ;)
Fair enough 👍 |
That's fine too, but a bit error more prone. If you copy over new code and forget about the namespace, you could easily make a VS quick action include mistake somewhere in DryIoc's source code unintentionally (there is a chance; but "fixing" the sources would discard this case entirely). ℹ️ to reason about current single-file situation: I think it's fine to go with the easy way and just rewrite the namespace in the target project |
implemented in DryIoc v5 |
Current simpton of trying to use ImTool with other projects that encapsulates this library is impossible.
It may sounds strange, but makes sense when DryIoc and ImTools itself is on different upgrade path in a project. The container will always be in lower version due to safety and compatibility, while in other parts of the project the new functionality of the ImTools could be benefical.
I would suggest using compile macro usage to differentiate the base namespace between embedded and normal usage of the library, thus making it easy for everyone.
Any response is appreciated. Thanks!
The text was updated successfully, but these errors were encountered: