I’ve upgraded my project today to Prism 6.3.0 and Unity 5.3.1. Before that, I had Prism 5 and Unity 4.
Now I’m running into problems with the Prism.Unity.UnityBootstrapper: it seems that the Container field is still a Microsoft.Practices.Unity.IUnityContainer instead of Unity.IUnityContainer.
I had hoped that the upgrade would cleanly cut all references to Microsoft.Practices.Unity off of my project, but it seems that I’m still forced to use the “old” Prism library, at least in parts.
Why does this situation arise, and what do I do to make it right? Am I missing something?
Unity 5.x is not supported in Prism yet. So, you will have to stick with 4.x until that happens. My understanding is, it is a goal of the team to support Unity 5.x in Prism 7 and up.
As you mentioned in your comment, there has been a lot of talk in the GitHub repo for Prism about the changes that came along with Unity 5. Glad to know that there are people willing to take on Unity, and move it forward, though.
Related
I am in the start of a new Prism.Forms project and I was wondering which of the various IoC containers (Autofac, Dryloc, Ninject or Unity) would be best to move forward with.
I do not know if this is true, but I read somewhere that Unity is no longer under active development and since this and MEF are the only IoC containers I have ever used I am unsure as to whether it is the way to go.
Meanwhile, I know little or nothing about Autofac, Dryloc or Ninject.
Please be objective in any advise, providing reasons why you feel one is better than the others rather than simply "I use xxx"; I would like to make an informed decision.
The best I can do is to layout the facts as they currently stand.
NOTE: A lot has changed since I first answered this in 2017. The information below has continued to be updated and should help you as you look to make decisions on your projects. Do take note however that you do also now have the ability to utilize the Prism.Container.Extensions as this provides support for abstracting many highly powerful registration methods including factories, and the ability to register a single implementation as a singleton for different services. Additional containers may be added there. Additional documentation for this can be found at https://prismplugins.com
Supported Containers
These are containers that ship officially from the Prism team
DryIoc
This is the container I use and recommend the most. It's under active development, it's very fast, and works well with the current release of Prism. Also important is that when I have had questions or issues the maintainer has been very quick to address the issue or answer the question I had. Dadhi is also very good at proactively providing enhancements for the Prism integration. It's for all of these reasons I continue to recommend the container. Unlike Unity the API tends to be very stable and I have not yet had an issue with updating DryIoc beyond what a particular release of Prism was targeting.
Unity Container
Not to be confused with the Unity Game Development Platform. This is the most popular container due to it being the container that Brian has used for years and it being the first (and for a long time only) container available in the Templates. It had gone quite some time without being maintained, however the project does have a new maintainer. It's worth noting that there were a number of breaking changes in Unity 5 which makes upgrading to Unity 5 with Prism 6.3 an impossibility. Prism has however updated to Unity 5 across all platforms in Prism 7. Unity is also about average with regards to its benchmark performance. For those upgrade to Prism 7 from Prism 6.X note that you should uninstall any references to Unity or the Common Service Locator and then update Prism.Unity.Forms which now targets the Unity.Container NuGet package instead of the Unity NuGet package. You should also beware that targeting a newer version of Unity than what Prism is built against may break your application as Unity has introduced a number of breaking changes without explanation or documentation from Minor Patch to Minor Patch.
Unofficially Supported
These are containers that have an unofficial package available. These may or may not work for you and are at your own risk.
Microsoft.Extensions.DependencyInjection
Prism requires certain features such as mutability and named services which are not supported by the Microsoft DependencyInjection pattern. There is however an implementation that provides universal support for all Prism applications/platforms from the Prism.Container.Extensions project.
End of Life / Deprecated Containers
While these containers have been used in many projects over the years the following containers are No Longer supported by the Prism team.
Autofac
Despite being popular, is a container I generally would advise against using. People seem to be very confused by the API. In Prism 6.3 it suffered from a really poor implementation. Sadly the Autofac team decided very strongly in order to improve performance that they would make the container immutable. Prism officially dropped support for this container as of Prism 7.1.
Ninject
Ninject was long one of the least utilized container. This was dropped from Prism.Forms in 7.0 as the team moved to support netstandard. While Ninject 3.3 does technically ship with a netstandard2.0 api, it's is not compatible with Xamarin targets. It is also currently in a very unhealthy state having the latest 3.3 release from November 2017 and the latest 4.0 preview from August 2016.
UPDATE
Well worth noting is that starting with Preview 5 of Prism 7 we have abstracted the containers. This will ultimately make it far easier to switch between the container of your choosing as the API is exactly the same with regards to how to register your services and Views. You will still have access to the Container and in the case of Autofac the ContainerBuilder through extension methods, so that you can accomplish more complex registrations.
// Prism 6.X way of Registering Services
protected override void RegisterTypes()
{
// Container Specific Registrations
// Autofac
Builder.RegisterType<DebugLogger>().As<ILoggerFacade>().SingleInstance();
// DryIoc
Container.Register<ILoggerFacade, DebugLogger>(reuse: Reuse.Singleton,
ifAlreadyRegistered: IfAlreadyRegistered.Replace);
// Ninject
Container.Bind<ILoggerFacade>().To<DebugLogger>().InSingletonScope();
// Unity
Container.RegisterType<ILoggerFacade, MCAnalyticsLogger>(new ContainerControlledLifetimeManager());
}
// Unified API in Prism 7
protected override void RegisterTypes(IContainerRegistry containerRegistry)
{
containerRegistry.RegisterSingleton<ILoggerFacade, DebugLogger>();
}
It is also important to remember that while Prism's IoC abstractions have made it easier to have a more unified API, this does not remove your ability to interact directly with the underlying Container. To access the underlying container you simply need to call the GetContainer extension method and you will be able to perform any more complex action that is not directly supported by Prism's IoC abstractions.
UPDATE 2
Prism 7.2 has introduced some API changes around the IoC Abstractions. Notably by and large these changes should not affect most users. However you may experience binary incompatibilities if using other libraries that reference older versions of Prism.
The IoC changes include:
A Fluent API
An ability to check if a service is registered
Added methods to allow both transient and singleton services to be Named Services
Added ability to resolve a service with specified instances.
As an owner of Flash Builder 4.6 I'm struggling with 2 problems in my web application:
XML parsing makes the whole application sluggish
Russian input in TextInput doesn't work with Opera
I wonder, if there is a new Flex SDK available for download, where some fixes might have been integrated since the Flash Builder 4.6 release several months ago.
So I have downloaded the "Flex SDK version 4.6.0.23201 is the latest production quality release" and installed it:
However this seems to be a version, which differs very little from the stock Flex SDK included with Flash Builder 4.6 originally.
My questions is: is there some good (i.e. fresh, but also tested/stable) source for Flex SDK, which would be suitable for Flash Builder 4.6?
Maybe I can check out the source from some repository and build it myself (how, please?).
Does Apache offer anything, since they are the new owners?
UPDATE:
I've checked out Apache's Flex with
svn co https://svn.apache.org/repos/asf/incubator/flex/trunk flex
(and have yet to figure out, how to build it) - isn't it newer and better?
is there some good (i.e. fresh, but also tested/stable) source for
Flex SDK, which would be suitable for Flash Builder 4.6?
Yes, that would be Adobe. I am not aware of any updates to Flex 4.6 since it's release late last November. It's only been three months. I believe the bulk of Adobe's work around Flex has been getting legal approval to submit Flex to Apache. They are getting that slowly.
You can download the source for the Adobe Flex SDK from opensource.adobe.com. Read this for info on getting the source from the Adobe SVN repository.
Does Apache offer anything, since they are the new owners?
The Apache project is still formally waiting for donations from Adobe, including their testing suite. But, some code is submitted from Adobe. A few people have submitted some new components, and there has been work done around localization. The Apache project does not have a formal release yet.
You should be able to get the Apache Source from SVN as an anonymous user. The trunk includes the framework dump from Adobe; but I haven't delved in myself. I know people have successfully built the Flex SDK from the Apache trunk. Here are some instructions on how to do it with IntelliJ
I should add that I'm not sure if updating the SDK will solve any XML parsing issues you have. But, it's tough to say for sure since you went into no details on what those issues are. My mobile game uses a 30K line, 1MB XML file for the level definitions and it has no problems parsing it effeciently.
Flex SDK sources
You can find the latest source code through the Flex Apache incubator page and use Subversion to check it out. However since the migration of the Flex SDK from Adobe to the Apache foundation is still very much in progress, I sincerely doubt that there would already be significant changes that would fix your issues.
The actual issues
XML parsing makes the whole application sluggish
XML parsing is a pure ActionScript matter and has nothing to do with Flex. It is closely related to how the Flash VM works, which is still closed property of Adobe. I don't think it is subject to change any time soon, mostly because I've heard very little complaints about its performance and the E4X language is one of the most powerfull around. If you're having performance issues better have a look at your architecture or work with AS model objects instead of XML.
Russian input in TextInput doesn't work with Opera
This is either related to the Flash VM (see above) or to the Text Layout Framework, which is "open-source", but still in the hands of Adobe. Whether it should also be contributed to Apache Flex is still being discussed. In both cases very little will change in the short future, so I think you'll have to try another approach.
Are you sure it has anything to do with the SDK? If the problem of cyrillic chars exists only in Opera - then it's more like a problem of Opera and its Flash-plugin.
This is what you get with Flex SDK 4.5 and Opera 11.61:
There might be another problem if you're using some font that doesn't have the cyrillic char subset (e.g. not using the default font). But if that were it, it would affect all browsers, not just Opera.
привет землякам!
Any issues? Does it replace 3.2? Appreciate the help/insight.
As long as Xcode 4 is a developer preview instead of a supported release, you are taking a big risk if you depend on Xcode for your livelihood. If you are interested only in hobby work, then the only thing you have to loose is a little hair (yes, there are several outstanding issues in preview 3). Once Xcode 4 is released, I think it provides many compelling features and I will happily move my development efforts over to the new version. Unlike Windows/Visual Studio, Xcode releases are not tied to operating system or library versions, and the Xcode team has made it so that versions 3 and 4 play very well together. So you can use either Xcode 3.x or Xcode 4 interchangeably.
Plain and simple: Because it's a Developer Preview! :)
(and personally: still crashes a lot on my machine)
And correct me if I'm wrong, but XCode4 still lacks several features.
Some basic features are also still not working as expected. When you write for Code Sense will suggest a long list for keywords. But the for-loop is still missing from the list. I am sure we all know how to write such a loop but for a beginner it still would be useful as it is in Xcode 3.2
I've found XCode 4 to be stable enough for daily work as of the DP5 release, and Apple is actually encouraging this now.
When (and you will) you run across things that don't work, or XCode crashes, just switch back to XCode 3.2 and work past the issue. The project file format is compatible so this isn't an issue at all.
Overall, XCode 4 is shaping up to be an awesome tool.
If you have a Core 2 Duo or earlier, DO NOT UPGRADE. Xcode 4 is a great tool with many wonderful additions, but slower Mac's can't handle it. You'll often find yourself typing then waiting for the editor to catch up.
I'm trying to find 1, just 1, working sample project for Red5 that's updated to work against the latest 0.9 release without missing jars and other nonsense.
Right now, it's at v0.9 and the libs are different from other versions. They have 5 pathetic examples on their website, but all were built with the older versions. For these 5 old examples, I could use the Add External JARS feature to try and add libs from previous versions, they don't mention which versions they were built against and I'm not going to try each previous version to see which works (I already did and nothing works). They don't seem to be putting any effort into updating or marketing their open source project.
Anyone who's more intelligent and can shed some light on behalf of these fools?
What sorts of issues are you having? What sorts of projects are you trying to build?
I'm by no means an expert on this - and I admit that the lack of documentation is pretty frustrating.
However, I just downloaded their latest, installed it and got the olfa demo running pretty seamlessly.
The source for the demos are available here, and I use these to work out what I need.
http://www.smartfoxserver.com/ makes use of red5 in someway. Perhaps you can find something useful in their (well documented) examples, good luck.
Is it realistic to try and learn and code a Flex 3 application without purchasing FlexBuilder? Since the SDK and BlazeDS are open source, it seems technically possible to develop without Flex Builder, but how realistic is it.
I would like to test out Flex but don't want to get into a situation where I am dependent on the purchase of FlexBuilder (at least not until I am confident and competent enough with the technology to recommend purchase to my employer).
I am experimenting right now, so I'm taking a long time and the trial license on my Windows machine has expired. Also Linux is my primary development platform and there is only an alpha available for Linux.
Most of the documentation I've found seem to use Flex Builder.
Maybe I should use Laszlo...
IntelliJ IDEA works as a Flex IDE, if you happen to also be a Java developer. It's free if you contribute to open source projects.
Check out FlashDevelop for Windows. I like it better than Flex Builder.
I've been using Flex since version 2 and Flex3/BlazeDS since it came out of beta. I also have some experience with Lazzlo and the difference is day and night (Flex rocks!). I have not regretted once using Flex. Regarding FlexBuilder, it is worth every penny. While it is completely possible and reasonable to write Flex application without FlexBuilder, the productivity gains of using it will more than recoup the investment. Try the evaluation for 30 days and compare it to some of the other options suggested about (I'm going to try FlashDevelop).
Some things you get with FlexBuilder include:
Code completion
Visual editor
Debugger (it is fantastic!!)
Profiler (also very good)
Regarding Linux, the alpha version of FlexBuilder does not have a visual editor. Other than that, I understand it is reasonably feature complete, still free, and many of the Adobe employees I've talked with that use Linux are happy with it.
FlashDevelop is really easy to setup with the Flex SDK. Just download FlashDevelop, then download the Flex SDK. In FlashDevelop go to Tools > Program Options > AS3Context (under Plugins) > Set the "Flex SDK Location" to the root of the folder you extracted the SDK to and build away. FlashDevelop even has a basic MXML project that will get you going.
If you use ColdFusion for the backend, having FlexBuilder in Eclipse and CFEclipse can mean one less IDE to have to get familiar with.
I'm going to join the choir here and say FlashDevelop for an alternative. The only reasons you might want FlexBuilder are:
Flex charts
Step-through debugging.
Profiler (I haven't used it)
Visual style editor
However, the code-completion and general bloody-awesomeness of FlashDevelop's code-completion and syntax highlighting knocks the gimpy eclipse crap out of the water. So, pretty much what Todd said, except for the code-completion part. Flex Builder is very flakey in that department.
Short answer: Yes
I'm working on a team of developers and designers. We code our .MXML and .AS in FlashDevelop 3 and our designer creates .FLA with skins and widgets that get [Import()]ed in ActionScript.
I wrote a little more about this subject here:
Flash designer/coder collaboration best practices
I have been using FlashDevelop for along time (4/5 years), I am actively using it to develop Flex4.5 applications, it has built in support for code completion, it has a profiler and a debugger that work excellently. The IDE itself is responsive and require the .Net framework, in fact here, I'll list some stuff.
FlashDevelop Pros
Free IDE
Code completion feature
Very capable Debugger
Profiler
Documenting
Ability to build Air / Flex files
Templating
Plugins
FlashDevelop Cons
Lack of UI desing support
.Net support only (Won't work with Mono)
Everything else is pretty simple to get running with, the instructions are available at http://www.flashdevelop.org/
Absolutely. I've been a Flex developer since Flex 2 and until recently I've used my regular editor, TextMate, for coding and Ant for building. TextMate has some good extensions for ActionScript and Flex coding, but I think you could get that for any decent editor.
What's been missing from my setup is a usable debugger, the command line version is a pain to work with. Because of that I've been starting to use FlexBuilder on the side, using it in parallel with my regular setup.
Having a profiler doesn't hurt too.
I've been using FlexBuilder for awhile now and just started to switch to using Eclipse with Flex SDK. I work for a non-profit so the word FREE is huge.
Initially, it is fairly intimidating so if you have the money, you might want FlexBuilder.
There is a lot you need to know and do if you use the SDK. The learning and experience may pay off though... I am still undecided myself.
I second FlashDevelop. You don't get the visual design stuff for the MXML, but for the code (both MXML and AS) it's excellent.
I also use FlashDevelop when working on AS3 projects. For me, the ugliness (UI design) and sluggishness of Eclipse/Flex Builder is enough of a deterrent to stay away from Flex Builder.
In addition to the weaknesses of FlashDevelop pointed out previously, one of my biggest gripes is that it is not a true .NET only app and therefore will never work in mono and therefore can not be easily ported to the mac - which is my platform of choice for development web/javascript/AS3 development.
Amethyst is also a pretty good option to try. It is a plugin for MS Visual Studio, and takes advantage of a lot of the goodies there. It is significantly less sluggish than FlashBuilder, has a really good debugger, and a decent visual designer as well.
The personal version is free, but quite crippled. You have to buy the pro version after a 60 day free trial. However, it is (at time of writing) almost 1/3 the cost of Flash Builder.
As an added bonus you don't need to pay for Visual Studio since it works with the free (albeit hard to find) "shell version (integrated)" of Visual Studio. It won't work with any of the free Express editions, though.