Skip to content
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

Closed
gnimor opened this issue May 13, 2019 · 8 comments
Closed

Installation parallel to Xceed #30

gnimor opened this issue May 13, 2019 · 8 comments

Comments

@gnimor
Copy link

gnimor commented May 13, 2019

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.

@Dirkster99
Copy link
Owner

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 :-(

@Dirkster99
Copy link
Owner

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:

  1. Dirkster99 AvalonDock project links to DLL projects to consume them:
    Dirkster99/AvalonDock -> Dirkster99/DLL_AvalonDock.Themes.Aero
    Dirkster99/AvalonDock -> Dirkster99/DLL_AvalonDock.Themes.Metro
    Dirkster99/AvalonDock -> Dirkster99/DLL_AvalonDock.Themes.VS2010
    Dirkster99/AvalonDock -> Dirkster99/DLL_AvalonDock

-> Dirkster99 can publish NuGets for each seperate DLL project (as it is already done)


  1. An additional project maintained by someone else links to DLL projects to consume them:
    XXXX/wpftoolkit -> Dirkster99/DLL_AvalonDock.Themes.Aero
    XXXX/wpftoolkit -> Dirkster99/DLL_AvalonDock.Themes.Metro
    XXXX/wpftoolkit -> Dirkster99/DLL_AvalonDock.Themes.VS2010
    XXXX/wpftoolkit -> Dirkster99/DLL_AvalonDock

-> 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 :-(

@gnimor
Copy link
Author

gnimor commented May 20, 2019

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 :-)
My problem is, that I am using the rest from the original package (for other controls). Now your branch regarding the Avalon Dock component contains all the great fixes for the docking itself - which is great. But your fixed library has the same name (Xceed.Wpf.AvalonDock.dll) as the original one. So when we have a nuget reference to the original package and to yours there is this naming issue (both libraries have the same name). The assembly version is different which is great. But when it comes to xcopy deployment it will be hard.

@Dirkster99
Copy link
Owner

Dirkster99 commented May 20, 2019

On a second thought, your problem can be solved quit easily - just download the complete WpfToolKip:

  1. uncompress
  2. Delete AvalonDock source files
  3. Add AvalonDockSource files via NuGet in VS
  4. Compile and publish on NuGet

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.

@gnimor
Copy link
Author

gnimor commented May 20, 2019

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.

@Dirkster99
Copy link
Owner

So, you:

  1. download the files and unzip the sources,

  2. Delete the sub-folders with the AvalonDock sources

  3. Open the solution in VS - you should see this:
    screenshot0

  4. Now, select the AvalonDock projects and delete them as well:
    screenshot1

  5. Now, right click th solution and select Manage Nuget packages for solution... to add each of the AvalonDock packages you just removed:
    screenshot2
    screenshot3
    screenshot4
    screenshot5

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.
Exit VS and browse into the sub-folder path:
wpftoolkit-master\ExtendedWPFToolkitSolution\Src\Xceed.Wpf.Toolkit\bin\Release

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

  • but if you are realy clever you will use an automated CI based tool which works with GitHub

  • because this will let you click re-build everytime you want an updated toolkit whenever I might have updated AvalonDock with another fix

  • that means you can publish another updated toolkit nuget without using your local computer

  • I can help you setting this up with AppVeyor provided you have created a GitHub Project with the above sources

@gnimor
Copy link
Author

gnimor commented May 20, 2019

Thank's for the detailed description. I will take a closer look!

@Dirkster99
Copy link
Owner

Hi,

I've put the above info into a Wiki page Use fixed AvalonDock with Extended Wpf Toolkit.
did the suggested workflow work for you? Can we close this issue now or do you need further infos?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants