I've got a WPF App using the latest version of Prism for WPF (6.3.0) and Unity. Just a few modules. It works great.
When I manage NuGet packages for my solution, it tells me that there is a new version of Unity (5.4.0) available. Unfortunately, if I try to update to that version, I can no longer build.
It's pretty clear to see why: Upgrading unity via this method removes all references to it (Unity) from my project. Specifically the following 3 references completely disappear from all my projects without any replacement:
Microsoft.Practices.Unity
Microsoft.Practices.Unity.Configuration
Microsoft.Practices.Unity.RegistrationByConvention
(The Prism references remain, of course)
Error messages tell me that IUnityContainer is defined in an unreferenced assembly (Microsoft.Practices.Unity. 4.0.0.0). Given that it removed those assemblies, this all makes sense.
If I then try to go looking to add Unity back in, the Add Project Reference dialog cannot even find Microsoft.Practices.Unity when I search for it.
Now this isn't that big of a deal. I didn't need to upgrade. and it's easy for me to revert back. But I want to understand why this is failing for future reference.
Does this mean that Prism is tied to the older version of Unity and I just shouldn't upgrade?
Does this mean that types have moved to different namespaces and I need to make some other fix?
Some other reason?
Among the Unity 5 updates included a change of namespaces which as you noticed was a major breaking change. There are no plans for Prism 6 to support Unity 5, however the current Prism 7 previews (which is available for WPF) have updated both the Common Service Locator and Unity.
https://www.nuget.org/packages/Prism.Unity/7.0.0.336-pre
Related
I have updated mac to 11.6 and xcode to 13.0. Realm could not compile so I updated it with carthage to v10.15.1. Now I get this runtime error just after the app launch:
Library not loaded: #rpath/Realm.framework/Realm
Referenced from: /Users/username/Library/Developer/Xcode/DerivedData/appname/Build/Products/Debug-iphonesimulator/RealmSwift.framework/RealmSwift
Reason: tried: '/Users/username/Library/Developer/Xcode/DerivedData/appname/Build/Products/Debug-iphonesimulator/Realm.framework/Realm' (file does not start with MH_MAGIC[_64], file does not start with MH_MAGIC[_64], fat file, but missing compatible architecture (have 'x86_64,i386', need 'x86_64')), '/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS.simruntime/Contents/Resources/RuntimeRoot/usr/lib/swift/Realm.framework/Realm' (no such file), '/usr/lib/swift/Realm.framework/Realm' (no such file), '/Users/username/Library/Developer/CoreSimulator/Devices/33E61712-D8A9-4D7E-A260-5C096BE08A82/data/Containers/Bundle/Application/AC700919-F431-446F-8BEF-FF8D8E5F5BF9/appname.a
I guess the key part here is file does not start with MH_MAGIC[_64], but I could not find anything useful about the error.
I tried embedding the library and turning off the embedding, does not affect anything.
Realm has 3 targets configured to be built with Carthage (Realm, Realm iOS Static and RealmSwift)
XCode 13 deprecated a setting for building targets in a manually set order which leads the first 2 targets to be built in a non deterministic order (the 3rd one is always last as it depends on the 1st one). The order and the frequency of it changing seems to be random (it might depend on the specific XCode version)
When 'Realm' is build before 'Realm iOS Static', the fat framework replaces the one in the xcframework which leads to that error. In the other case, it's the correct one that's built second and overrides the wrong one.
I guess the solution (apart from upgrading Realm) would be to remove the target 'Realm iOS Static' from the project but it's not straightforward to do with Carthage except by forking Realm
The latest version of realm is v10.32.0. xcode 14.1 is also out.
You need to update your toolset.
The latest upgrade realm version 10.32.0 is compatible with XCode 13.1 and above. If you use the legacy build system, migrate it to the latest one and clean the derivable folder before rebuilding the code. Most of the time derivable keeps track of the older version files and makes conflicts once you update the project tools. Hope this will help
I have implemented a Xamarin.Forms effect and spiked i successfully but I now need to create a proper NugGet package to use it as a component in my projects.
I added a .NET Standard lib for the RoutedEffect implementation. Then created three platform-specific lib projects for iOS, Android and UWP. To try everything out I then created a new Xamarin.Forms app with a .NET Standard "common" lib that references the RoutedEffect´s .NET Standard lib. Finally, from the iOS app I reference both the RoutedEffect's lib and the (iOS) PlatformEffect implementation lib.
The problem is that the PlatformEffect never gets instantiated. I tried resolving it from the .NET Standard common lib, just to see what's going on, and I just get back a NullEffect. For sake of sanity I then tried moving the code for the iOS PlatformEffect from its iOS lib into the iOS app. This works. But I have no idea why it won't work when implemented in the iOS lib, when referenced from the iOS app.
Am I missing something?
Ok, this was a bit embarrasing, and an example why you shouldn't code late in the night I guess. :-/
After a good night's sleep I realized the PlatformEffect lib, which consist of one effect only, was only referenced from the iOS project but none of the lib's types was actually referenced and, so, the .NET linker won't link the lib.
Just adding a reference to the platform Effect type solved the problem and it works fine.
Please move on ... :-)
My custom class library (targeting .NET 4.5.1) references Newtonsoft.Json 8.0.2 (the latest version to date). I've added this class library as a reference to a new ASP.NET 5 Web API project.
From the Error List output:
Error NU1002 The dependency Newtonsoft.Json 1.0.0 in project MyProject does not support framework DNXCore,Version=v5.0.
That part seems somewhat self-explanatory, however, I couldn't understand why it was changing my referenced version to 1.0.0.
From the References --> DNX 4.5.1 --> MyClassLibrary Node:
NU1007 Dependency specified was Newtonsoft.Json >= 8.0.2 but ended up with Newtonsoft.Json 1.0.0.
I've tried removing/re-adding the references several times, all to no avail. I did notice that several of the ASP.NET libraries use Newtonsoft.Json 6.0.6 -- I'm not sure if this has anything to do with it.
If I navigate to the wrap folder --> Newtonsoft.Json --> json file, and replace "Newtonsoft.Json 1.0.0-*" with "Newtonsoft.Json 8.0.2-*", it fixes the references for the DNX 4.5.1 node.
However, errors still show afterwards saying that Newtonsoft.Json 8.0.2 referenced in my class library does not support DNXCore 50.
I'm at a loss as to what to do. Any help would be greatly appreciated.
Answer to my issue:
Thanks to Oleg's response I was able to make it work -- however there were two hurdles. One was the "wrap" folder that was created for Newtonsoft.Json. In the root of my solution was a "wrap" folder that contained a folder called Newtonsoft.Json. Apparently(?) that folder shouldn't have been created (how it was created I have no idea). Once removing that, I was able to add a reference to my custom class library without any errors referencing Newtonsoft.Json.
However when I began trying to use my custom assembly as in code, I would get an error about DNX50 not being supported -- which sort've makes sense because my custom referenced assembly was a .NET 4.5.1 class library.
This GitHub link has many people experiencing a similar issue
However, I managed to get everything to build and errors to go away by removing targeting for DNXCore50. This worked for me because I was just wanting to share some POCO data models between a Web API and WPF project. I'm not interested in targeting DNXCore at the moment.
I'm looking forward to the future of ASP.NET, but the newness is a bit challenging, at least for me.
I am using Spring Source Tool Suite 2.8.1 to implement Spring applications.
I frequently get build errors because references are lost for no apparent reason. In Right-click project in Package Explorer->Properties->Java Build Path->Order and Export, I find projects sometimes are deselected. And often packages are gone in Right-click project in Package Explorer->Properties->Java Build Path->Deployment Assembly.
Having to reset these settings frequently is frustrating. Is there some way I can work around these problems?
I have tried to update STS to the latest version, but the upgrade process fails with incomprehensible error messages. I want to avoid a clean install because setting up the environment again would probably be a nightmare.
Now that I know this is a maven project and you are adding references yourself, this is making sense to me. STS 2.8.x was the last STS to ship with the legacy m2e (maven plugin for Eclipse). It did not recognize build path entries added manually (it likes to have complete control over the classpath). So, what is likely happening is that you are adding these classpath entries and then an update project operation gets kicked off automatically. This will have the effect of removing all of your extra classpath entries.
You are best off doing the following:
Updgrading STS
Or just upgrading your m2e component (you will have to first uninstall the old m2e, but this should be taken care of automatically from the discovery update page).
Or, just accept the fact that you can't manually change your classpath with the legacy m2e.
I have just mavenized the Apache Flex 4.9 SDK. Now, how can I build my application with maven?
Does anybody have an example pom-File for this?
Is there a flex-mojos version out yet, which is working with this flex version? Or are there any alternatives?
Btw.: My application is running, when I build it with Flash Builder 4.7.
I'm the guy currently in charge of continuing the development of Flexmojos.
I have to say, that RIAstars comment is not correct. I created the Mavenizer for usage with an updated version of Flexmojos and it is reported to work quite nicely together with it. Unfortunately I haven't released FM6 yet as I wanted to have it stable first. Because of this you have to fetch my github fork from https://github.com/chrisdutz/flexmojos ... I was planning on merging my changes back to the public repo as soon as Atlassian finally sets up our GIT repo at https://flexmojos.atlassian.net
I am currently working on making FM6 a parity release to the FM5 but with the difference that it works with the fdks generated by the mavenizer. What is true, is that I will not add any new features to FM, such as native Air bundling for mobile devices and support for falcon.
This is because we have already started the development of a purely Apache maven plugin that should replace FM one day. The main reason is the enormous effort you have to invest in maintaining a plugin that builds all FDKs starting with Flex 2.x and eliminating some design problems that were causing a lot of support traffic on the mailinglist.
So I would say: Yes you can use the Mavenizer to mavenize your FDKs and then you use FM6 to build your apps with it because that's what I created them for :-)
FlexMojos as it is will no longer be developed for future versions of Flex. As such I don't think you'll be able to use it with your mavenized version of Flex (but I might be wrong; I'm not exactly certain how it all works).
However the current maintainer of FlexMojos (Christofer Dutz) is working on a brand new Flex/Maven plugin. So for future versions you should be able to use that. Unfortunately to my knowledge this projects is far from finished.
As an alternative there is GradleFx which is a plugin for Gradle. You can set up an Apache Flex SDK dependency simply like this:
dependencies {
flexSDK group: 'org.apache', name: 'apache-flex-sdk', version: '4.9.0', ext: 'zip'
}
repositories {
add(new org.apache.ivy.plugins.resolver.URLResolver()) {
name = 'Apache'
addArtifactPattern 'http://apache.cu.be/flex/4.9.0/binaries/[module]-[revision]-bin.[ext]'
}
}
Personally I find Gradle much easier to work with than Maven. (Disclaimer: I am a contributor to the GradleFx project, but I only became one because I loved it so much).