I have to create a universal app from scratch. First the classic app, and at some point in the future, the modern app. I have generated the app using Cmd.
I have implemented the basics I need for the classic app, split off everything that can be reused in the modern app and put it into the shared directory. The problem is that now, when I compile with Cmd, I get the error that dependencies are missing (because views are missing in the modern app that I have implemented for classic only, but are required in shared code).
The classic app compiles find, but modern doesn't, and if there are ever errors in the classic app build process, no one will notice, because modern throws errors.
Can I tell Cmd on the command line to only compile the classic toolkit?
In ExtJS 6 we can generate app for classic and modern separately in a similar fashion we can can build app separately for classic and modern.
you can build like this.
sencha app build -c classic.
Edit the app.json file, and remove the section about the modern toolkit in the builds profile section; you can re-instate it when you're ready to build the modern part again.
Related
I'm new to this topic and couldn't find any guides concerning this. I'm wondering how the Today Extension files from a xcode project (originated from the CN1 iOS debug build sources) needs to be added to the actual CN1 project in order to get integrated properly.
We don't have builtin support for that and didn't really study it. We never had official support for Android widgets either.
Both can be used through native code though. E.g. in this case you can use ios.plistInject to add the necessary plist changes. The actual UI/code that implements them should be done in a native interface anyway.
We already have a working UWP app for x86, x64 and ARM. Everything is fine regarding store certification, all tests are passed, including with .NET native compilation.
We would like to use the Desktop Bridge (similar to what is specified here: https://blogs.msdn.microsoft.com/appconsult/2016/12/19/desktop-bridge-the-migrate-phase-invoking-a-win32-process-from-a-uwp-app/) to add a small .NET 4.6.1 WPF side-kick app to the main UWP (x86, x64) versions. The WPF app has three dependencies(x86 and x64) on some native dll's which are packaged together with the rest of the app.
We added the WPF.exe app and dll's to the existing UWP package (like specified in the above blog post - using xcopy) and built packages for HockeyApp. Locally and functionally, everything works fine for both x86 and x64. Once uploaded to the ms dev center, the Store certification unfortunately fails with the following error:
"Package acceptance validation error: Apps converted with the Desktop
Bridge and that require the .NET Native framework must be pre-compiled
by the .NET Native tool chain"
-- but native compilation is already enabled for UWP Release x86, x64.
We then tried to create a Windows Application Packaging Project (like described here: https://learn.microsoft.com/en-us/windows/uwp/porting/desktop-to-uwp-packaging-dot-net#generate-packages-for-your-desktop-bridge-app) and add both the UWP app and the WPF as dependencies. Then we created a new app manifest and store association (unfortunately it does not seem possible to reuse the existing manifest from the UWP app). We built the app store packages for (x86 x64 Release) and successfully tested everything locally. We then uploaded the package to win dev center and got again the same errors as before
"Package acceptance validation error: Apps converted with the Desktop
Bridge and that require the .NET Native framework must be pre-compiled
by the .NET Native tool chain".
As a follow up we removed the UWP project from the Windows Application Packaging Project and set the WPF app as an entry point. We then built a store package, uploaded it and the .NET native compilation error disappeared. Which is very weird...
Somehow the combination of UWP and WPF (even with native compilation enabled for UWP) causes this certification error. We have a feeling that something is wrong with the packaging.
We would really want to get this combination working or we will have to fall back to having two separate apps: one pure UWP and one packaged WPF companion app which needs to be installed separately. We truly wish we wouldn't have to do this. I'm not sure what we are doing wrong and for the moment I have run out of ideas.
PS: We also know we need to fill and submit a form regarding the restricted capability: full trust. But before we do that we need to be sure that everything else is fine.
UPDATE 4/21/2018
The workaround explained below is no longer needed, and in fact will not be accepted by the Store anymore. The right way to properly package a UWP app with a Win32 extension is to use the new VS Packaging Project, and then create the store package off of that project in VS. Details are in this blog post, see example #3 for this specific case:
https://blogs.windows.com/buildingapps/2017/12/04/extend-desktop-application-windows-10-features-using-new-visual-studio-application-packaging-project/#uvfV1r7937WrSkX2.97
OUTDATED ANSWER BELOW
You are hitting a known flaw in the Store ingestion process for packages that contain a mix of UWP and Desktop .NET binaries. The Store team is actively working on resolving this, so it will work automatically for submissions of this type. In the meantime you can do the following to get unblocked:
Manually create your.appxupload as follows (see screenshots for clarity below):
Go to the output folder for the AppPackage
Select the .appxsym files and the .appxbundle file
Create a new .zip file from those
Rename the .zip file to .appxupload
Resubmit to the Store with the new .appxupload file
I have an eclipse codenameone project. I would like to execute this project on Eclipse using my own codenameone modified sources (codenameone sources project is in netbeans). How could I do that ?
As it is mentioned in this video, we should linked the project in the build path but it works only if we have a netbean project.
Better solution is to edit Codenameone source in Eclipse (but sources in github has structure of a Netbeans project).
Thanks!
Right now debugging with the Codename One sources is only supported on NetBeans because that is the platforms we use for our coding. It's harder to work with other IDE's and might not be worth your effort.
Someone posted a while back in the discussion forum about running this in Eclipse but I couldn't find the reference.
Generally if you want to build the native sources and debug from there just work based on the logic we have and adapt it to Eclipse (or any other IDE). Running a Codename One project has 2 major dependencies:
Codename One project - that's a regular Java project you can work with
JavaSEPort another regular project, this is the implementation of the Codename One code and includes the simulator.
Make sure to add the source trees of both these projects to the compile but not packaging phases and set the Simulator class as your main class.
If you are successful in doing this it would be really nice if you write about it for the developer guide wiki next to the NetBeans build and explain how this is done for future developers.
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.
I am new to MonoDroid so maybe there is an easy answer, but so far searching hasn't turned it up... Since deploying to the Android emulator takes _for_ever_ on my PC, I would like to put most of my logic into a separate library and test it from a separate winforms application. Later, I can build a regular MonoAndroid application that provides the UI and just calls the library. However, when I try to link to the MonoAndroid class library I get this message:
Warning 1 The project 'MonoAndroidClassLibrary1' cannot be referenced. The referenced project is targeted to a different framework family (MonoAndroid)
Is there another way to achieve this objective? Yes, I could simply create a separate standard windows library and copy/paste the code between the two, but there must be a better way
You can use this extension http://msdn.microsoft.com/en-us/library/ff921108%28v=pandp.20%29.aspx
You would need to create a regular .Net 2.0/3.5/4.0/etc class library and copy (or link) your source code files into it. Use this assembly for testing in winforms, and the Android class library copy for Android.
Of course, this will only allow you to write code that doesn't reference anything in the Mono.Android.dll assembly.