For an Windows app, the option for the default language is found in Package.appxmanifest under the project. However, I do not know where to find the setting for a class library, because there is nothing like Package.appxmanifest under a class library project.
As a result, after I add Strings\zh-CN\Resources.resw and a few strings into a class library project, I get a few warnings, saying:
MakePRI : warning 0xdef00522: Resources found for language(s) 'zh-cn' but no resources found for default language(s): 'en-US'. Change the default language or qualify resources with the default language. http://go.microsoft.com/fwlink/?LinkId=231899
MakePRI : warning 0xdef01051: No default or neutral resource given for '...'. The application may throw an exception for certain user configurations when retrieving the resources.
No actual help from "fwlink" as usual.
Although nothing bad actually happens because the app gets zh-CN as its default language, it is still quite annoying and I would like to eliminate the warnings to turn on "treat warnings as errors".
Try to manually edit the <DefaultLanguage> in the csproj file. It's under the first <PropertyGroup> subtree.
Here is a snippet of the context where you should be able to find this tag:
<DefaultLanguage>zh-CN</DefaultLanguage>
<TargetPlatformIdentifier>UAP</TargetPlatformIdentifier>
<TargetPlatformVersion>10.0.10240.0</TargetPlatformVersion>
<TargetPlatformMinVersion>10.0.10240.0</TargetPlatformMinVersion>
<MinimumVisualStudioVersion>14</MinimumVisualStudioVersion>
Related
By default, when editing a JavaScript file in VSCode, it will assume that the fetch function and related types exist in the current context. This makes sense for JavaScript designed to run in the browser, but when running on node.js the fetch function does not exist unless it is installed via node-fetch. I find that in this context, VSCode is misleading, as it will not highlight an error when you trying calling the fetch function, or access other types such as Request and Response, even though they do not exist unless you have node-fetch installed.
How can I configure vscode to assume a node.js context, and therefore assume that fetch does not exist unless I explicitly import it from node-fetch?
Why web types are there by default
From the docs for tsconfig.json compilerOptions.lib:
TypeScript includes a default set of type definitions for built-in JS APIs (like Math), as well as type definitions for things found in browser environments (like document).
How to change the defaults
Create a tsconfig.json or jsconfig.json, and set the compilerOptions.lib array to not contain "DOM", which means that lib.dom.d.ts (the "DOM standard library" type definitions file that comes with TypeScript) will not be assumed. You should specify which ECMA Script standard you want to write your source code in.
The config file also has fields to control what files it takes effect on: files, include, and exclude. If you specify none of them, include will default to **, which matches everything beside and recursively under subdirectories beside the config file.
Having to create this file could be seen as annoying if you just want to write a single JS file (ie. now you have a whole config file just for one source file!). I don't know if there are alternatives that are more convenient for such a use case. If anyone knows, please edit this answer.
I looked briefly into TypeScript triple-slash directives, which allow specifying things on a per-file basis, but I think you can only add things (ie. I don't think you can use them to remove a lib).
At the time of this writing, there are VS Code settings that can be applied at the user-settings scope that affect settings for implicit projects (JS/TS files which don't have a project config file) (js/ts.implicitProjectConfig.*), but none of them are for setting the compileOptions.lib field, and my gut says it's probably not going to happen (but don't quote me on that).
You probably also want types for the Node API
Use npm to install a version of #types/node. Make sure the major version number of the version you install matches the major version number of the version of Node JS you want to script to be runnable on.
Fun irrelevant facts to this question
Continuing on the point about VS Code's user-settings for implicit projects, VS Code puts some defaults in effect (on top of those that TypeScript itself does) if no project is detected. You can poke through the code at github.dev/microsoft/vscode by doing "Find in Files", using extensions/typescript-language-features/**/* as the "files to include" field, and compilerOptions as the find query. compilerOptions.lib seems to not be something that VS Code touches in such a scenario.
I am attempting to convert parts of an Android app to iOS using Doppl, and I am getting a strange result: Doppl keeps trying to pull in android.arch.lifecycle:reactivestreams, even though I don't want it to.
Specifically, in app/build/j2objcSrcGenMain/android/arch/lifecycle/, there is a reactivestrams/ subdirectory with R.h and R.m files in it. This seems to make Xcode cranky and may explain why I had some oddities with pod install.
My app/build.gradle has compile "android.arch.lifecycle:reactivestreams:$archVer", because my activity is using LiveDataReactiveStreams.fromPublisher(). However:
The activity is not in the translatePattern (and since its code is not showing up in app/build/j2objcSrcGenMain/, I have to assume that the translatePattern is fine)
I do not have a doppl statement related to reactivestreams, because there does not appear to be a Doppl conversion of this library (nor should it be needed here)
AFAIK, nowhere else in this app am I referring to LiveDataReactiveStreams, which AFAIK is the one-and-only public class from the reactivestreams library
So, the questions:
What determines whether Doppl creates R.h and R.m files for some dependency? It's not the existence of a doppl statement, as I have doppl statements for a lot of other dependencies (RxJava, RxAndroid, Retrofit) and those do not get R.h and R.m files. It's not whether the dependency is referenced from generated code, as my repository definitely uses RxJava and Retrofit, yet there are no R files for those.
How can I figure out why Doppl generates R.h and R.m for reactivestreams?
Once I get this cleared up... do I re-run pod install, or is there some other pod command to refresh an existing pod with a new implementation?
Look into 'app/build/generated/source/r/debug' and confirm there's an R.java being created for the architecture component. It'll be under 'android/arch/lifecycle/reactivestrams'.
I think there are 2 problems here.
Problem 1
Somehow Doppl/J2objc is of the opinion that this file should be transpiled. It could be either that 'translatePattern' matches with it, or that something in the shared code is referencing it. If you can't figure out which, please post a comment and I'll try to help (or post in slack group).
Problem 2
Regardless of why that 'R.java' is being sucked into the translate step, because of how stock J2objc is configured, the code is being generated with package folders instead of creating One Big Name. That generated file should be called 'AndroidArchLifecycleReactivestramsR.h' (and AndroidArchLifecycleReactivestramsR.m). Xcode really doesn't like package folders. That's why there's a slightly custom J2ojbc being used with Doppl, so we can have files with big names instead of folders.
In cases where you intentionally use package names that match with what J2objc considers to be "system" classes, you need to provide a header mapping file to force long names. The 'androidbase' doppl library needs to add a lot of files that are in the 'android' package, which J2objc considers "system". We override those names in the mapping file.
build.gradle
https://github.com/doppllib/core-doppl/blob/master/androidbase/build.gradle#L19
mapping file
https://github.com/doppllib/core-doppl/blob/master/androidbase/src/main/java/androidbase.mappings
I screwed up.
In my dopplConfig, I have:
translatePattern {
include '**/api/**'
include '**/arch/**'
include '**/RepositoryTest.java'
}
In this case, **/arch/** not only matches my arch package, but also the arch package from the Architecture Components.
Ordinarily, this would not matter, because the Architecture Components source code is not in my project. But, R.java gets generated, due to resources, and the translatePattern includes generated source code in addition to lovingly hand-crafted source code. So, that's where my extraneous Objective-C was coming from.
Many thanks to Kevin Galligan for his assistance with this, out on the #newbiehelp Doppl Slack channel!
Since upgrading to Gradle 3.3 I'm having trouble building my code due to missing-translation errors:
Error: xxx is not translated in "af" (Afrikaans), "am" (Amharic), "ar" (Arabic), "az" (Azerbaijani), "az-AZ" (Azerbaijani: Azerbaijan), "be" (Belarusian), "bg" (Bulgarian), "ca" (Catalan), [...], "zh-TW" (Chinese: Taiwan), "zu" (Zulu) [MissingTranslation]
The majority of the reported languages are those supported by a 3rd-party module included in my project, and it now seems to define the supported languages for the entire project, giving me this kind of error for all strings that are not translated into above languages. Before upgrading to Gradle 3.3 this was not causing any problems.
I considered the following solutions:
Remove surplus translations from other modules. I want to avoid that because those modules are external and needlessly altering them would really hurt maintainability of my project.
Disable the "incomplete translation" Lint inspection - the most common suggestion for similar questions on SO. This is sub-optimal because I want to be made aware of translations that are missing in my code (working so far). Besides that, disabling the check does not get rid of the error.
Define the supported configurations in build.gradle as described in this answer. I like this option (specifying languages instead of relying on translations available in the modules), but it also does something strange: I'm getting missing-translation errors for strings that are marked translatable = false.
For now, I'm downgrading again to the previous Gradle version. But what is the best apporach for fixing these build errors?
Hoping that there might have been corrections since I posted this question a few months ago, I checked the situation.
It seems that the issues were introduced with the Gradle plugin 2.3.0 and not Gradle 3.3 itself as I suggested in the question. Downgrading the plugin avoids the errors but can hardly be a long-term solution.
I found that option 3 in the question is the best way to handle it: add this to the app's build.gradle:
android {
defaultConfig {
...
resConfigs "en", "fr"
}
}
This is described in Googles documentation and, as mentioned, also in this answer. It removes all unnecessary resources - and the warnings/errors along with them.
Quoting the documentation:
The Gradle resource shrinker removes only resources that are not referenced by your app code, which means it will not remove alternative resources for different device configurations. If necessary, you can use the Android Gradle plugin's resConfigs property to remove alternative resource files that your app does not need.
For example, if you are using a library that includes language
resources (such as AppCompat or Google Play Services), then your APK
includes all translated language strings for the messages in those
libraries whether the rest of your app is translated to the same
languages or not. If you'd like to keep only the languages that your
app officially supports, you can specify those languages using the
resConfig property. Any resources for languages not specified are
removed.
The "false positives" (missing translation error for a non-translatable string) I got were for strings that were defined in more than one module. Renaming the strings or providing translations for them solved the problem. This, too, seems to be introduced with Gradle plugin 2.3.0.
In build.gradle add below code
lintOptions {
disable 'MissingTranslation'
}
I ran into the following error which is quite surprising. I added a field to the AppSettings in a Yesod app (using the Yesod scaffholding) and to my surprise, everything compiled even though I didn't do anything else (I was expecting to have to add somewhere a default value to the construction of AppSettings, but not). I got a runtime error instead telling me that a field was missing.
It appears that the only construction to AppSetting uses the RecordWildCards extension and looks like AppSettings{..}. Not defining the new field didn't generate an error but a warning (I didn't see it, because I was running test in continuous mode using stack test --file-watch). How is that possible ?
I try to reproduce the problem in a simple file and I get an error not a warning. So why do I get a warning for Yesod ? Is it a compilation flag or something ?
Edit
This is not specific to Yesod. I've made the test again with a simple file and it generates a warning not an error.
According to changelog in GHC, "that not a bug, it's a feature": https://ghc.haskell.org/trac/ghc/ticket/5334
You can change this behavior by changing type of your fields to strict (prepend a ! to type name - like !Int) - however, then you lose laziness (more about effects of strict types: Advantages of strict fields in data types)
Of course, you can also make it an error by slamming in -Werror compilation option, but then you need to be very strict about your code (no unused imports, no unused variables, even when unpacking a record etc.), or get rid of -Wall and turn on only warnings you perceive as important.
I have a project that is running fine on Android and WinPhone 8. When I attempt to run on iOS, I've getting the following error
Microsoft.Practices.ServiceLocation.ActivationException: Cannot
register: No public constructor found in x
where x is whatever SimpleIoc.Default.Register<T, TU>(); the flow hits first. I've moved the code around (as suggested elsewhere) to ensure all of the platform specific SimpleIoc calls are made in ViewModelLocator.
I've added public default ctors in the classes that are complaining about the error (I have though set the PreferredConstructor to the original, not the newly added public ctor).
I have a feeling that this error is a false positive (something else is failing, but pointing at that code).
Using Xam.iOS via a build server (the code is coming from VS2015). Xcode is running the 8.3 emulators (it may need updating to allow for 8.4 testing)
It could be that the Linker is optimising away the constructor, if it thinks it's not used. Try setting the Linker Options to "Don't Link" and see if it does it again, or even new-up an instance of the class elsewhere so that the Linker knows that the constructor is used. You don't necessarily want to leave it that way, but if it eliminates the error, you'll at least know the reason.
The [Preserve] attribute did the trick for me.
Decorate constructor with it and keep your linker settings.
This attribute is part of the Microsoft.WindowsAzure.MobileServices namespace.