How can I use it on WinRT (Windows 8) - I can't compile it. Can I use it also with "normal" Windows (WPF)?
There isn't currently an mvvmcross port specifically for wpf - a couple of people have suggested building one, but the majority of users have so far requested more work on mobile platforms instead. There is a current console (win32) port and extending that towards WPF should be quite straight-forward.
Future development is now based around the Portable Library branch - see some info on http://slodge.blogspot.co.uk/2012/09/mvvmcross-vnext-portable-class.html and the code on https://github.com/slodge/MvvmCross/tree/vnext
For WinRT, the TwitterSearch example within the vNext branch is a good place to start - it should compile and work across all of MonoTouch, MonoDroid, WP7, WinRT and Console:
If you find you can't compile then please log specific compiler error messages either here or to github issues.
MvvmCrossLibs\MvvmCrossLibs.sln consists of many projects, requiring different runtimes to be installed to open properly (Mono Touch, Mono Droid, WP7). If you only need the library in WinRT, your best bet is to open Cirrious\Cirrious.MvvmCross\Cirrious.MvvmCross.WinRT.csproj directly and add the missing Newtonsoft.JSON package with NuGet (you'll need to save the automatically created .sln file before that). It should compile just fine after that, at keast it did for me. Now just reference the assembly in your Windows Store app project and start using it.
I don't have any previous experience with MVVMCross, but it doesn't look like it currently supports despktop WPF apps. I don't know how difficult it would be to create/compile such a version, though.
Related
We have a situation with word addins where we try to load our taskpane and use cefglue implementation to show web page. We use cefglue for the same. We just discovered that one of the vendor addins also loads chromium but an older version. Unfortunately our addin shows a message that it cant load chromium due to hash difference.
Now is it possible that 2 COM addins can load different version of chromium? The vendor change looks unlikely and I could see they don't use cefglue or cefsharp but have their own implementation. Has anyone in this situation before? We are thinking of moving our code base to use same version as theirs but again when they upgrade, we have to upgrade and we will have a window where this fails due to incompatible version. thanks
It seems there is no easy answer to this problem as word / excel can load only one libcef dll in memory. The redgate apphost could be a possible solution and I added a link to cefsharp remoting repo which I am still trying to make work but has some readymade code and could be a good starting point for someone trying to do the same thing. Best of luck and thanks #amaitland for pointers.
I am planning to start updating some old-ish C code to C99, hosted publicly on GitHub. The code compiles without a single change on Linux, macOS and Windows.
To ease poking about in the code, on my Mac I used an Xcode project file to organize it. I believe other users might find this useful too, and on .Net as well.
So, my question is purely organizational - does anyone out there have a canonical example of how to arrange such a project physically? That is, a widely used example that has Mac, Win and Linux builds using platform specific project files and make/make config
I know can just put the project files in subfolders, but I want to be sure that if there is a "standard" way to do this that I use it too.
When I create new Windows Phone project I have an option to create a "Windows Phone" or "Windows Phone Silverlight" app. I know that they have different runtimes and different APIs.
I was under the impression that Microsoft wants to unify Windows and Windows Phone platforms so why is there even a Silverlight version? What benefits does it bring?
Also, if I want to create an app just for Windows Phone and never have plans to bring it to Windows, what should I choose, Silverlight or Windows Phone?
I'd suggest you go with "Windows Phone" (non-Silverlight). It's the new API, which works for both Windows and Windows Phone. At some point you may want to port the app or create a new one for Windows and you'll already know the API (and porting will be way easier). Also, the new API will most likely get more updates and features added, and at some point you may even be forced to update to it (either because the old one is no longer supported, or because it does not have some features that you need).
As it was said in the other answers - the Silverlight option is there only for backward compatibility and is likely to be phased out in time. That is - it's good if you already know the API and have many libraries (yours or others) for WP Silverlight, but if you're just starting - you'd better go for the new technology.
Edit
There is one other thing to consider before choosing between the two types of apps. Some features are only available in a Silverlight app, and others (smaller amount) - only in a Xaml app. Here's an article with some info on the differences: Migrating your Windows Phone 8 app to a Windows Runtime XAML app
Windows RT Xaml is quite new and People have to generate some knowledge first.
Silverlight for phone has been around for years and there's a load of tools available: Phone Toolkit, diverse Controls, etc.
Just killing it off would have hurt many developers who built up intellectual property over a long time forcing them to start over.
When starting a project with Silverlight you will have more things around that help you get stuff done.
When starting with WinRT Xaml, you will have better performance, but will have to figure a lot out by yourself.
So the Silverlight option is there to not throw of Silverlight developers.
I recently started a new project on WinRT Xaml and my experience was that I had to recreate a lot of common tools like Caches, etc. But also a lot of things that were in Toolkits previously are now part of the platform itself. Also, when moving over to Windows 8, you get to share a lot of code which is nice.
Unifying the environment(s) would be ideal. In my opinion, it hasn't been very successful. At one point in time, you could only develop under Silverlight, so what you are seeing is just a newer version of the same thing to keep backwards compatibility as well as to keep Silverlight's developers happy. In the future, it will probably be phased out. Plus if you want to support older Phones, Silverlight is basically your only choice (you'll be surprise, how many WP users haven't updated their 8.0 to 8.1)
There really isn't any other real benefit of Silverlight other than maybe the Windows Phone Toolkit which has been tremendously useful (you can see how many SO's answers rely on this simple addon). Once the universal runtime gets fleshed out to the point where the documentation reflects what's actually available -- then I think it would be the default project for developing in Windows going forward.
If you're just starting, I would use Silverlight the knowledge based is much greater. After you get use to the WP environment then switch to runtime.
I'm planning web application and considering silverlight as development platform. Will it help to solve browser compatibility issues? The app intended to be used on desktops only (no mobile).
Yes, it will solve browser compatibility issues, and could work on both Mac OS and Windows with the very same code.
The only drawback is that, the first time your user connect to your application, he will need to download the Silverlight plugin.
Awesome you would say? Well, unfortunately some people that probably never try to do something like image processing or advanced line of business application in a browser decide that plugins are not so cool and that you would be able to do the same thing with the magic power of HTML5.
We are still waiting to have the same possibility in HTML5 that we have in Silverlight or Flash, but plugins are already dead. At least as long as no big compay want to push them again.
So, my advice would be: don't start a project in Silverlight. You will have problems, even if you do not target mobile. For example it becomes harder and harder to find compatible good tools (like ReSharper, NCrunch, or even just a decent unit testing library). And in further release of Windows and Mac OS, it will probably not be supported at all (IE for Windows RT already does not support Silverlight).
Sorry man, Silverlight is dead, you arrive after the battle.
If your developing your application for an Intranet, I would say Silverlight is an excellent choice.
If you are developing for the Internet, use an HTML based language
I'm trying to port my existing silverlight project to xbox Lakeview.
I got a compilation error saying "System.Windows.Browser" is not supported in ADK
and in Microsoft.Xbox360.Adk.targets "System.Windows.Browser.dll" is listed as the
unsupported assemblies.
I'm using APIs such as "System.Windows.Browser.HtmlPage" and
"System.Windows.Browser.HttpUtility". How can I work around it?
I'm not sure if you've gotten this figured out or not, but my version of the ADK I don't believe supports this namespace. If you would like to send me yours, I'd be more than happy to lend a hand in figuring out what's causing this issue.
LakeView is a profile of the .NET framework that is in accordance with Silverlight, but is not the same as the SL Runtime.
For instance, there is no "Browser" when running a LakeView app on your devkit.
You have a special bootstrapped container in one process that your Title will be contained within, which makes it more like a full-fledged application running in a portable OS than a Silverlight application.
What are you trying to achieve with your interaction with the HTMLPage?
Can you redirect your HttpUtility usage to the System.Net.WebUtility?