-
Notifications
You must be signed in to change notification settings - Fork 324
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
Installation parallel to Xceed #30
Comments
Hi, I understand your issue as it has been raised by another user before. But my 'problem' is that I am just one human being spending more than enough life time on making AvalonDock run as stable as it should. Plus, I already mentioned in the other thread why I would not want to depend on a monolitic toolkit like the WPFToolkit from Xceed, plus I am not using that toolkit myself, so, I realy have no interest in also maintaining the rest of the toolkit. But as I wrote in the other thread, if someone wants to contribute with their own time I am sure that we can find a solution for producing a Nuget with the fixes for AvalonDock plus the rest of the toolkit - for me as a single person its not within scope I am afraid :-( |
Here is what I mean by sharing the projects if someone else is willing to invest their time: We could use Git-Subtree or Git-Submodules to seperate out DLL projects into seperate DLL repositories and then have other repositories link to them:
-> Dirkster99 can publish NuGets for each seperate DLL project (as it is already done)
-> XXXX publishes NuGet for complete wpftoolkit + AvalonDock DLL projects Lez me know if you were willing to invest time to look into 2) - you don't need to understand it right now as we can explore it together, but as long as I am the only one investing my time its going to be to big for one person I am afraid :-( |
Sorry for the delay. I understand that you do not have the time to maintain the complete Xceed package. My issue request was also not about having fixes for all other Xceed libraries :-) |
On a second thought, your problem can be solved quit easily - just download the complete WpfToolKip:
Now you or someone else should be able to do that and if not its not going to be available. Please read my previously linked comment to understand why I am not maintaining a complete WpfToolkit/Nuget solution. |
Thanks for your update. Not sure if I understood this correctly. "3. Add AvalonDockSoure files via NuGet in VS" so how can I add the source files via NuGet in VS? Sorry if this seems to be a stupid question. |
So, you:
You should now be able to compile and checkout the application within the LiveExplorer (which you do not need for the NuGet publishing but its up to you if you leave it or not). Now, once you have compiled and tested it, be sure to Select Release and Build it one more time. Here, you should see all the binaries that you want in your nuget - how you create and publish your nuget package is up to you - there are many ways to do it
|
Thank's for the detailed description. I will take a closer look! |
Hi, I've put the above info into a Wiki page Use fixed AvalonDock with Extended Wpf Toolkit. |
First of all thanks for the great work you did in your Avalon Dock branch. Currently I am using this implementation because of the fixed issues in your branch compared to the original Xceed branch. Now I am in a situation where I want to use some other controls from the original Xceed branch but the docking stuff from yours (some of my assemblies are still using the Nuget package from Xceed and one is using yours). All libraries are loaded via Nuget. Currently the assembly version is different 3.5.0.0 compared to 3.5.4.0 which is good but I think not really enough. Both assemblies have the same name which makes it impossible to do a xcopy deployment. Do you have a suggestions to handle this? I could compile your package myself and give the assembly a different name but then I loose all the advantages of Nuget.
The text was updated successfully, but these errors were encountered: