I had an open-source spare-time project two years ago where I used the free 60 controls by DevExpress, from the link here: https://www.devexpress.com/Products/Free/NetOffer/
I was vey happy with these and I even personally recommended these controls here.
My project now is quite old, but now I want to make some minor changes, and I just experienced, to my surprise, that I will no longer be able to build it, because I took a dependency on those controls. I did not copy these DevXpress libraries locally, so I really lost them.
What can I do about these now missing controls? Does anybody faced the same already? Should I replace them (quite a lot of work, because I do not want to change the UI at all now), or does someone still have these around?
My mind just had a glitch :-/ These DLL's are of course found in my installer package. I just installed my own software from codeplex, where I published it, searched thru the Harddisk and voilà, here the are, listed:
DevExpress.Data.v10.2.cdf-ms
DevExpress.Data.v10.2.dll
DevExpress.Data.v10.2.manifest
DevExpress.Utils.v10.2.cdf-ms
DevExpress.Utils.v10.2.dll
DevExpress.Utils.v10.2.manifest
DevExpress.XtraBars.v10.2.cdf-ms
DevExpress.XtraBars.v10.2.dll
DevExpress.XtraBars.v10.2.manifest
DevExpress.XtraEditors.v10.2.cdf-ms
DevExpress.XtraEditors.v10.2.dll
DevExpress.XtraEditors.v10.2.manifest
DevExpress.XtraTreeList.v10.2.cdf-ms
DevExpress.XtraTreeList.v10.2.dll
DevExpress.XtraTreeList.v10.2.manifest
DevExpress.XtraVerticalGrid.v10.2.cdf-ms
DevExpress.XtraVerticalGrid.v10.2.dll
DevExpress.XtraVerticalGrid.v10.2.manifest
So, just in case, anyone needs those DLL's (The original 60 controls suite consisted of more files, however), you can get them the same way from my installer.
I would guess this is legal, since distribution in my project (with LGPL v2) was also legal.
latest free control is version 11.2 you can download it from github
Related
I have a WPF application built on .Net 4.8, Prism and Unity, using PackageReference in the project files. Every once in a while I update Nuget references to the newest ones. The packages related to Prism and Unity repeatedly have been a pain in the arse.
Now is such a moment again. Or rather, the past DAYS. I am trying to use packages like
Prism.Wpf 7.2.0.1422
Unity.Container 5.11.8
I keep bumping into the dreaded "The located assembly's manifest definition does not match the assembly reference", again & again in various variations. Seeing warnings like "Found conflicts between different versions of ... that could not be resolved", or "explicit binding redirect on ... conflicts with an autogenerated binding redirect".
I have been tinkering with this a lot, checking a whole dependency tree, removing, adding, or changing redirects, adding or removing packages. Of course searching on the web. It has driven me nuts. How to get out of this, and prevent it for the future?!
I don't know if this is combination of bugs somewhere, or just me not understanding how to use it. So I will put this as a question.
How on earth am I supposed to get things working?!
Set AutoGenerateBindingRedirects or not?
Set explicit redirects or not? If so, for which versions, to which other version? What about the publicKeyToken?
What about testing projects using MSTest, Moq, Appium, do they need a different approach?
Frankly, I was under the impression that using Nuget to install packages would just take care of all that, particularly using PackageReference. Well apparently, it doesn't.
I am at a loss. Is there anyone who can direct me to a valid approach?
Thanks in advance!
As I write this question, 2 days after the beta of .NET 4.5 was released, the What's New in WPF 4.5 Version 4.5 Beta page on MSDN still lists "Integrating WPF with win32 Graphical User Interfaces" as an area in which WPF 4.5 offers improvements. That page talks about the two new properties on HwndHost that support this: IsRedirected and CompositionMode. Also, the top-level what's new in .NET 4.5 beta page mentions this integration as a new feature.
Again, as I write this, there are pages for those two items. You've got IsRedirected here and CompositionMode here. (Update 27th Jan 2014: original pages no longer available, so I've moved these links to point to the Internet Archive copies.)
However, if you go to the docs for HwndHost itself, neither of those properties is present. And they don't appear to be in Visual Studio either.
So it would appear that the rumours are true - it looks like the airspace improvements for interop have been dropped. But just in case anyone from Microsoft is reading this, it would be good if a) we could get positive confirmation and b) the pages mentioned above could be updated to stop getting our hopes up.
Update 27th Jan 2014: I've updated the links for IsRedirected and CompositionMode to point into the Internet Archive, because the original links are now dead. Also note that the What's New pages no longer mention this because those links are now for the final release. You can see the old pages that were current when I originally asked this question at this archived page and here.
There is a rather good blog post from Dwayne Need that describes the extraordinary effort they put in trying to make it work. Nothing subtle, they for example ending up intercepting over 200 GDI functions to get them to play along with the WPF rendering model. The outcome was to be expected:
You can imaging my heartbreak when, after an extensive review, we decided we could not actually ship this feature. Our concern was that we had to hack too deeply into the system, and in ways that were too difficult to explain - let alone maintain. Even though we required that developers explicitly turn on this feature for each HwndHost, we felt the kinds of problems they would encounter would be baffling to them and training our support engineers to handle the escalations would be very difficult. Even towards the end of our development, we were struggling with a long bug tail and performance concerns.
This is exactly the kind of deep system integration that needs to be done by the Win32 platform team, officially sanctioned and supported. With Win8, we are beginning to see some incremental improvements in this space, as noted before in the DirectComposition API. Unfortunately, it is still not possible to build the same kind of rich composited experience we had developed.
Whether the Windows group is going to commit to providing this kind of integration is right now an open question. They certainly put their money on a very different horse and spent a lot of effort on WinRT, a rendering model that's certainly inspired by WPF but doesn't do anything to make it better. If it is going to be tackled at all then count on years to get there.
Do check the rest of the blog post as well. It has excellent, albeit it high-level, advice on addressing existing airspace issues.
A suggestion to "Bring back the HwndHost.IsRedirected and CompositionMode" was posted at the Visual Studio UserVoice.
Microsoft declined it, saying:
at this time, we will not be able to add the feature to WPF and the .NET Framework.
It also looks like the MSDN pages you linked to have been taken down.
Got a Win7 box with VS2010 Premium installed on it.
Building desktop apps works just fine.
But we got this solution with 15 SL4 and 21 desktop projects... Building the SL part of it takes too long. This is very irritating and encourages to drop TDD since every time I run a test it takes ~3 seconds for msbuild to find out that nothing changed and the project should be skipped. The projects are very small and there's nothing fancy in them and we hadn't any problems before we switched from VS2008+SL3.
I've heard people complaining abound VS2010 speed in general, but nothing about SL4 build time.
Is anyone experiencing same problems and is there any workaround for this?
Do you need that many projects? As a rule of thumb, less is better. You say that the projects are very small, that would be an indication to me that you probably don't need that many.
Don't use it for managing dependencies (cycle avoidance). If you're trying to manage 'units of development' or logical groupings, use namespaces instead.
Physical/project separation is good for keeping test code out of production code, and managing units of deployment, but don't separate it until you're getting something out of it.
Patricks Smaccia wrote a good article on when and when not to create assemblies.
Another way to tackle the problem is to break your solution up into multiple solutions, and
use references to the dlls produced by the other solutions. That way, you only build part of it at a time. If you need to work across many dlls at the same time, this is inconvenient, but it's a sign that something is likely to be wrong with the design of your code.
This post on speeding vs.net up with many projects may also help.
I notice most of the discussions about Blackberry database options are old, and generally not too informative.
As of today, March 31st, 2010, what is the best, most universally supported, free database option available for Blackberry developers?
I heard SQLite is available for JDE v5, but last I checked, that was still in beta, and I didn't want to commit to developing on a system that is not supported by most of the phones in service.
Thing is, I don't see any dates on these claims. For all I know, the announcements I am reading are from 2008.
So, I am still on v 4.7. I need to use a relational DB for the app I am developing, but there aren't many resources for DB handling available - or at least resources that are useful to me. I find a lot of "tutorials" that assume you know everything there is to know about Blackberry development, or Java. But no complete classes or anything. Many of these examples don't even work. Eclipse gives warnings and errors from code copied and pasted from other people's examples.
I can answer any questions that may assist in this case. Hopefully, this thread will help many BB developers in the future.
Before v5 I don't think there is a native relational database that you can work with on the Blackberry, the closest thing is the Persistant Store API, however I think that there are 3rd party libraries that you can use, like SQL Anywhere.
Depending on the Java dialect supported on your Blackberry version, db4o could also work well for your usecase. It's an object database, quite similar to Perst.
Ok, in case anyone has had similar experiences with this, here is what I have done:
The JAR class path thing was resolved through no help at all from these sites.
What I did to get an outside JAR included in my package was to right click the package name in the navigation menu (Eclipse) - then select Build Path - then add libraries.
From this I was able to modify an existing library to include the JAR for the perst package.
Now I am able to import org.garret.perst.*
We'll see if there are any complications.
Forgive the number of posts, maybe it will help someone else down the way.
We are implementing an application that needs dockable windows, similar to Visual Studio 2005/2008, but with multiple "docking sites", unlike VS's single one. Does anyone have a recommendation on a good library for this - either OSS or commercial? I am aware that Infragistics has one, as well as Divelement's SandDock and WPF-Dock from DevComponents, as well as ActiPro's Docking & MDI product. There is also one on CodeProject. Has anyone used any of these libraries? Was the experience good or bad? If you have experience with one of them, does it support multiple "docking sites"?
The one from Codeproject is the AvalonDock - we use it for more then half a year now, but we're far from release yet so we have the flexibility. Before ending up with AvalonDock we tried Infragistix, ActiPro, SandDock and may be some others.
Even though AvalonDock is not 100% bug free (well what is?) there are no major ones, it is very stable, fast and has all the functionality. It does support multiple docking sites.
Its an open source project and is in active development, so bugs are beeing found and fixed. Good experience so far.
I've been using the ActiPro library for several months and it's done me well. It does support multiple docking sites. The support is outstanding and you get some other controls (date picker, etc) that are missing from WPF. To me, for $150 it's money well spent. It worked out of the box, no fuss.
We used to use Divelements for WinForm controls but we think Actipro has better support, so we switched for WPF.
Just my two cents.
Don't forget AvalonDock on GitHub (part of WPF Toolkit). I've seen it mentioned in other places.
Initially I was going to use the ActiPro library (mostly because I am already using their ribbon), but I might give AvalonDock a chance since it is open source.
Anybody have any feedback/comments on AvalonDock?
I use DotNetBar, because it has ribbon/dock and more controls, and it's inexpensive. It's great.
http://www.devcomponents.com/dotnetbar-wpf/
SandDock is alright. We used it for a POC phase of a project. I found some pretty bad bugs in their layout saving mechanism. It generated XML, but then couldn't load this XML back; it threw an exception! I actually read through all the generated XML and had to write code to modify the XML slightly after each time it was generated. It did not seem like it was a well thought out design; I was hoping for common WPF base types like
Infragistics is a bit better but buggy. In fact, if you try running it on a machine that only has .Net 3.0 and no .Net 3.5, it doesn't work correctly. Have an outstanding dev issue with Infragistics and I don't know if they've made any progress on a fix for this. I've also had it crash a few times when floating a window and dragging it around (suspect this has to do with the .Net 3.0/3.5 issue above). I've found styling this control to be pretty un-intuitive.
I tried all the libraries listed here and they're all buggy to some extent. Although they are pricy I would recommend Telerik and Infragistics. Nevron merits a mention because their library is the best I've seen but it's for WinForms.
1 year later ...
AvalonDock is now stable and robust.
There's also an "AvalonDock wrapper" that simplifies working with it without reducing its possibilities.
See http://sofawpf.codeplex.com/
Here is another one:
http://www.essentialobjects.com/Products/EOWpf/DockView.aspx
This one has a number of built-in skins that you can switch dynamically. It also has many individual controls (such as a "Splitter" control) that you can use independently.