I have a solution with a main project that uses Prism 5 (WPF). This solution also contains many more projects that are Prism modules.
Now I have to create a new module, and I wonder if I can use Prism 6 only in that module, and it will be compatible with Prism 5 main project, or if I need to continue with Prism 5 in all the modules (or upgrade the entire solution to Prism 6, what is a really big work).
Thank you
You'll have to stick with Prism 5 or upgrade everything to Prism 6. There are some breaking changes between these versions:
Removed all types that were marked as "Obsolete" in Prism 5
Removed IView interface
Changed namespaces to remove Microsoft namespaces
Moved a number of types around to better organize and to get as much into a single Portable Class Library as possible
ViewModelLocator naming convention changes: [Name]View now requires [Name]ViewModel. No longer [Name]ViewViewModel
Source: https://github.com/PrismLibrary/Prism/blob/master/README.md
The namespace change alone is already enough to 'break' your application. You'll now have 2 different instances of e.g. EventAggregator (as they live in a different namespace).
Related
I am trying to load views and viewmodels in a module using app.config and Prism 7.1.0.279-pre. I cannot find any post anywhere that seems to get this to work. Does anyone have any examples?
I have a basic understanding from MEF when it was early on. I would like to be able to create apps with multiple reusable modules and would like to get this to work.
You should use the ConfigurationModuleCatalog.
Therefore, you need a ModulesConfigurationSection in your app.config named modules. This is where you define the modules to load.
An example is in the documentation.
BTW - Prism 7 has dropped support for MEF. Use a container like unity or dryioc for dependency injection and reserve MEF for plugin system.
Am trying to install SIGNALR to my asp.net project, but when adding the Nugets, it keeps pushing an error that the "Package xxx was restored using .NETFramework, Version=v4.6.1 instead of the project framework .NETCoreApp, Version=v2.0". I get this error on several Nugets. I tried to re-install all Nuget one by one but same result when I arrive at some particular one like SIGNALR.
I believe I might have something wrong in the setup, but as am new to asp.net, would love a pointer. Read the literature but could not find the answer to this issue.
It also looks like SignalR might only be available for netcore 2.1 later this year but am looking for a way to use it, in a simple app.
So a couple of things.
For the latest SignalR Core bits you need to be targeting netcoreapp2.1. Preview1 and later depend on that.
If you want to just experiment with SignalR targeting netcoreapp2.0 the alpha 2 bits use netcoreapp2.0. But just to be clear the alpha bits are just a public preview and should not be used for production applications.
The main thing here though is that you are using the Microsoft.AspNet.SignalR packages. Those will not work on Core.
I am using Xamarin and need to use a PCL
However, I cannot install ServiceStack into the PCL other than the PCL package which is classed as no longer being maintained
Has anyone come across this?
I want to use PCL because I dont want to duplicate code
PCLs are supposed to be supported via the latest Service Stack but this does not appear to be the case
I have code which makes use of ToJson which is in ServiceStack.TExt
I know I could create a folder inside my iphone (and android) assemblies but I am not sure this is a good approach because it doesnt feel right (everything all in one place instead of in proper layers)
Does anyone have any ideas about this?
Paul
Your assumptions aren't correct, ServiceStack PCL Packages ARE still being maintained, but instead of being maintained in individual packages, e.g:
ServiceStack.Client.Pcl
ServiceStack.Text.Pcl
ServiceStack.Interfaces.Pcl
They have now been merged as different profiles into the main client NuGet packages, e.g:
ServiceStack.Client
ServiceStack.Text
ServiceStack.Interfaces
I'm not a developer myself, but my company develops and supports a large web application for insurance brokers.
Since way back we've been using ExtJS 3.x and as we went further the harder it got to migrate from 3.x to 4 and now to ExtJS 5. Due to the structure of the application and demands from out customers we cannot afford to freeze development and focus on refactoring our interfaces.
But we still want to use the benefits and functionality of the ExtJS 5.
My question is - is it possible to use both versions of the framework in the same application? For example, developing new grids and modules with ExtJS 5 and gradually migrating existing forms.
Did anybody have this sort of experience? Or is it plain nonsense and will never work?
Thanks to everyone in advance.
I find this question very interesting. I had a similar challenge, when I had to migrate our in house app from legacy Jxlib to ExtJs4. Putting my experience together with #Lolo's answer here is what I can advice:
Build on a new solid foundation. You could be tempted to keep your app in ExtJs 3.0 and start grafting new ExtJs 5.0 components on it. If you really want to take advantage of all the new features of ExtJs 5.0, you should start off with a clean, simple MVC app in ExtJs 5.0, that could be as little as the main window and the main menu. You could then bind all existing menu entries to the existing ExtJs 3.0 code. This will allow you to start with a really clean thing, keeping all the old functionality, without rewriting the code, and allow you to develop all new features with clean ExtJs 5.0 code that follows current best practice recommendations.
You will face two stumbling blocks:
You have to separate the namespaces in Javascript and CSS. Here also, I would advice to change the prefixes for ExtJs 3.0, and not for Ext 5.0 (I ignore if ExtJs 5.0 includes a sandbox file). The reason behind is that all your new ExtJs 5.0 code will be standard compatible, while only the old legacy code becomes incompatible (what it is anyway already). This will represent some code refactoring though, because you would need to replace all Ext. occurrencies in all your code with Ext3. or similar (the same applies to CSS, but will be much less work). I hope for you, that ExtJs 3.0 has a sandbox version, because I think refactoring their code would be a lot of work (but not impossible).
A major feature of ExtJs 5.0 (as already for version 4.x) is the automatic building and compiling of an MVC application using Sencha Cmd. This didn't exist yet for ExtJs 3.0. I think it is crucial that you start straight away using this tool. I will allow you to really take advantage of all the enhancements (declarative programming instead of imperative, advanced MVC and MVVM features). It will radically change your coding style.
To get this work, you compile in a first step you old code in one Javascript file. Sencha Cmd must not recognize this as an Ext app. Then you simply add requires: 'Oldapp' in Application.js and ExtJs will include a file called Oldapp.js. That file should define a class Oldapp and include all the rest of your application code:
Ext.define('Oldapp', {
// Just what ever you need
})
// All the rest of the code of you old app
Then layout all the folders and files of your new code according to the MVC or MVVM specification (whatever you prefer) in the Ext doc, and Sencha Cmd will build you the whole app correctly.
I think this all allows you to take advantage of all the new features immediately, building on a clean, standard foundation with only minor code refactoring. It sounds like eat the cake and have it too, but it is possible.
But this will take a huge mental step: You must learn ExtJs 5.0 like something new and try to forget all you know already about ExtJs. You won't use Ext.ready anymore, Ext.Loader will handle this under the hood. Nor will you instantiate Ext objects from declarations (ban panel = Ext.create({xtype: 'panel', ... stuff), stick to Ext.define('Myapp.view.Mypanel' .... There are many other points where everything changed since Ext 3.0 ...
This last point is in my opinion the biggest stumbling block, much more important than the two technical points explained before: It is difficult, but crucial to reeducate yourself.
You can use sandbox version of Ext Js 5.0 and "normal" 3.0 (I don't remember if 3.0 is also available as sandbox).
Then you can change prefix for all 5.0 classes and css rules. By default it is Ext4 (not Ext5) for JS, and x4- for CSS.
To use sandbox include ext-all-sandbox.js file from build directory.
It won't work. The javascript files will clash with each other.
I have an extension package on our corporate nuget server for Asp.Net MVC 3 - let's say the package ID is currently Acme.Mvc and it's version is 2.x.
I've now branched that project and going to put a pre-release version of the same package targetted at MVC 4 Beta. Now, logically this is now version 3.x of the library; however, as soon as I release it (once it's no longer pre-release), the 2.x will no longer appear in VS' UI; which will potentially lead to other developers adding it to their MVC 3 projects; and deny them easy access to any future upgrades to the older v2.x library without using the console).
In a couple of other cases, I've changed the package id to include a version i.e. Acme.Mvc.3 so the new and old can sit side by side. Only problem with that is that it's then possible for someone to try and include both! There's also the slightly pedantic issue that to call that v3.x is not necessarily correct; because it's a new package.
Also, I really need to be able to maintain both streams. I can rely on Binding Redirects in MVC 4 sites that still reference the version of the library that targets MVC 3; since none of my extensions rely on stuff that's gone.
When I look at the public nuget feeds; I rarely ever see this practise of sticking a major version in the package ID, but is there really any alternative?
There are many existing packages that uses the MVC version as part of their naming convention to differentiate between supported versions :
WindowsAzure.WebRole.MVC3
Unity.Mvc3
Spark.Web.Mvc2
Spark.Web.Mvc3
...
"Only problem with that is that it's then possible for someone to try and include both!"
I wouldn't bother trying to block this case, it would seem obvious by the name of the package that both are not meant to be side-by-side.