Running aapt against my apk, I see that something is appending a hash in front of my activity name, where I'd normally expect to see my namespace. Here is the aapt output...
C:\Program Files (x86)\Android\android-sdk\build-tools\23.0.1>aapt dump badging c:\base.apk
package: name='fr.company.DematAEAT_Android' versionCode='1' versionName='1.0' platformBuildVersionName='4.0.4-1406430'
install-location:'auto'
sdkVersion:'11'
uses-permission: name='android.permission.INTERNET'
uses-permission: name='android.permission.READ_EXTERNAL_STORAGE'
application-label:'DematAEAT_Android'
application-icon-160:'res/drawable/icon.png'
application: label='DematAEAT_Android' icon='res/drawable/icon.png'
application-debuggable
launchable-activity: name='md5abda05033ab0415fc7a776c5d9734c74.MainActivity' label='DematAEAT_Android' icon='res/drawable/icon.png'
feature-group: label=''
uses-feature: name='android.hardware.touchscreen'
uses-implied-feature: name='android.hardware.touchscreen' reason='default feature for all apps'
main
other-activities
other-receivers
supports-screens: 'small' 'normal' 'large' 'xlarge'
supports-any-density: 'true'
locales: '--_--'
densities: '160'
native-code: 'arm64-v8a' 'armeabi' 'armeabi-v7a' 'x86' 'x86_64'
The problem is on the line that starts "launchable-activity". How can I create intents that point to my activity if it's buried in a namespace with a long, made-up and, I expect, frequently changing namespace?
This was something added in a recent Xamarin.Android version, also announced in the changelog to prevent clashing names I guess.
You can circumvent this by either using the RegiterAttribute or by forcing a name in the ActivityAttribute:
[Register("myNamespace.ActivityName")]
[Activity()]
public class MyActivity : Activity {...}
or
[Activity(Name = "myNamespace.ActivityName")]
public class MyActivity : Activity {...}
Related
I installed Redis StackExchange nuget and things worked fine. But then I installed RedisSessionStateProvider nuget, which installed StackExchange.Redis.StrongName along with it.
Now I am getting the following error,
Error 107 The type 'StackExchange.Redis.IDatabase' exists in both
'e:\Source\packages\StackExchange.Redis.1.0.481\lib\net45\StackExchange.Redis.dll'
and
'e:\Source\packages\StackExchange.Redis.StrongName.1.0.481\lib\net45\StackExchange.Redis.StrongName.dll' E:\Source\MyApp\Helpers\RedisHelper\StackExchangeRedisExtensions.cs 13 37 MyApp
Why is this?
There's a lot of confusion between the strong-named dll and the non-strong-named dll namespaces.
You can easily solve this by using extern alias.
Right click on project references and pick the dll you want to refer, go to properties window. Then, change the Aliases field value to anything you want. E.g: "Redis".
Then go to your consumer source-file and add:
extern alias Redis;
using System;
// ... other references
using Redis::StackExchange.Redis;
namespace Foo
{
public class Program
{
public static void Main(string[] args)
{
using (ConnectionMultiplexer connection = ConnectionMultiplexer.Connect("myConn"))
{
// use StackExchange API here.
}
}
}
}
There's also an issue on StackExchange's repository explaining more about StrongName vs Non-StrongName.
Some methods/properties/interfaces are duplicated in above 2 dlls.
Remove StackExchange.Redis reference to resolve errors.
I faced this issue in an ASP.NET Core app, and this answer solved my issue quickly.
After registering File and Json plugins I get "Failed to resolve type Cirrious.MvvmCross.Plugins.File.IMvxFileStore." I am not registering a custom MvxFileStore, but the default implementations.
Reading the documentation once those two plugins are loaded I should get a registered implementation for IMvxFileStore (https://github.com/MvvmCross/MvvmCross/wiki/MvvmCross-plugins#file)
My registration of the plugins is the following:
Bootstrap folder
public class FilePluginBootstrap :
MvxLoaderPluginBootstrapAction<PluginLoader, Plugin>{}
public class JsonPluginBootstrap :
MvxPluginBootstrapAction<PluginLoader>{}
Is there anything I can do to confirm the plugins are loaded? Application Output doesn't show any errors trying to load plugins.
Small but important detail is not to forget to call base.PerformBootstrapActions() in Setup.cs.
Running the application with grails run-app works fine but after deploying in Tomcat 7 I get following error.
groovy.lang.MissingMethodException:
No signature of method: static com.digithurst.hdspro.web.Responder.respond()
is applicable for argument types: (ResourceListCmd, QueryCmd, groovy.util.ConfigObject)
values: [ResourceListCmd#5c380e, ...]
Possible solutions: respond(HttpResource, java.lang.Object, java.lang.String)
As already said, this works outside of Tomcat. The way the method is called is exactly as it is implemented. The ResourceListCmd implements the interface HttpResource which makes it a perfect fit. This error also occurs if the first parameter is null.
groovy.lang.MissingMethodException:
No signature of method: static com.digithurst.hdspro.web.Responder.respond()
is applicable for argument types: (null, QueryCmd, groovy.util.ConfigObject)
values: [null, ...]
Possible solutions: respond(HttpResource, java.lang.Object, java.lang.String)
More on the environment:
Windows 7 64 Bit
Java 7 U45 x86
Grails 2.3.4
Tomcat 7.0.47
I have already cleaned the .grails and .m2 folders in the user directory and performed a grails clean berfore creating the war file.
[Edit after answer of H3rnst]
Controller:
def index() {
try {
ResourceListCmd configs = configService.search()
respond Responder.respond(configs, new QueryCmd(level: 'list'),
grailsApplication.config.grails.serverURL)
}
catch (Exception e) {
render status: INTERNAL_SERVER_ERROR
}
}
ResourceListCmd:
interface HttpResource {
...
}
abstract class AbstractHttpResource implements HttpResource {
...
}
class ResourceListCmd extends AbstractHttpResource {
...
}
Responder:
class Responder {
static def respond(HttpResource resource, def query, String serverURL) {
...
}
}
Your war (or tomcat server classpath) contain a duplicate or wrong version of jar that contains the class com.digithurst.hdspro.web.Responder. (The version of the class you are using developing an launching with run-app is different from the one tomcat load running your war)
You could try to unpack the war end verify the version of the problematic jar and/or use a tool like jarscan to scan for duplicate classes.
You could even try to use the command dependecy-report and search for duplicate injection of the same lib. Probably two different plugins your are using are incorporating to differente versions of the same lib causing the problem.
marko's suggestion doing run-war actually gave the final clue to solving this thing. It wasn't a problem with Tomcat but rather the environment the app was running in. run-app as well as run-war both use the "development" environment by default and therefore it worked. Only in "production" it did not, which is what is used when deployed to Tomcat.
The actual culprit was part of the configuration and the error message was right, although unexpected. I'm calling the Responder.respond() method with grailsApplication.config.grails.serverURL. The serverURL was only set in "development" mode but not in "production". That's why Groovy/Java complained about the method signature:
(ResourceListCmd, QueryCmd, groovy.util.ConfigObject) vs (HttpResource, java.lang.Object, java.lang.String)
The clue is the last parameter, the first two are correct. However, I would've expected null as the value instead of a completely different type.
I have written this code which compiles and works perfectly in VS.NET 2010
module ConfigHandler
open System
open System.Xml
open System.Configuration
let GetConnectionString (key : string) =
ConfigurationManager.ConnectionStrings.Item(key).ConnectionString
however when I do a control + A and Alt + Enter to send this to FSI I get an error
ConfigHandler.fs(2,1): error FS0010: Unexpected start of structured construct in definition. Expected '=' or other token.
OK.
So I change my code to
module ConfigHandler =
open System
open System.Xml
open System.Configuration
let GetConnectionString (key : string) =
ConfigurationManager.ConnectionStrings.Item(key).ConnectionString
Now Control + A, Alt + Enter is successful and I FSI nicely tells me
module ConfigHandler = begin
val GetConnectionString : string -> string
end
However now If I try to compile my code in VS.NET 2010, I get an error message
Files in libraries or multiple-file applications must begin with a namespace or module declaration, e.g. 'namespace SomeNamespace.SubNamespace' or 'module SomeNamespace.SomeModule'
How can I have both? Ability to compile in VS.NET and the ability to send modules to FSI?
There is a tiny -- but crucial -- difference between your two snippets of code which is to blame here.
F# has two ways to declare a module. The first, a "top-level module", is declared like this:
module MyModule
// ... code goes here
The other way to declare a module is as a "local module", like so:
module MyModule =
// ... code goes here
The main differences between the "top-level" and "local" declarations are that the local declaration is followed by an = sign and the code within a "local" module must be indented.
The reason you get the ConfigHandler.fs(2,1): error FS0010: Unexpected start of structured construct in definition. Expected '=' or other token. message for the first snippet is that you can't declare top-level modules in fsi.
When you added the = sign to your module definition, it changed from a top-level module to a local module. From there, you got the error Files in libraries or multiple-file applications must begin with a namespace or module declaration, e.g. 'namespace SomeNamespace.SubNamespace' or 'module SomeNamespace.SomeModule' because local modules must be nested within a top-level module or a namespace. fsi doesn't allow you to define namespaces (or top-level modules), so if you want to copy-paste the entire file into fsi the only way it'll work is if you use the compilation directives as #pad mentioned. Otherwise, you can simply copy-paste the local module definitions (without the containing namespace) into fsi and they should work as expected.
Reference:
Modules (F#) on MSDN
The common solution is to keep the first example and create a fsx file which references the module:
#load "ConfigHandler.fs"
You have advantage of loading multiple modules and writing plumbing code for experiment.
If you really want to load ConfigHandler.fs directly to F# Interactive, you can use INTERACTIVE symbol and compiler directives:
#if INTERACTIVE
#else
module ConfigHandler
#endif
which works for both fsi and fsc.
If I compile the following module into a dll
namespace MyNs
module SomeModule =
do printfn "module loading"
let x = 23
then reference the dll in FSI and execute the command open MyNs.SomeModule "module loading" does not print immediately. It only prints when I access x which causes all the top level let and do bindings to execute (normal behavior I know in the .NET world). Is there any way, perhaps via an attribute on the module, I can indicate that module should load immediately upon opening in FSI?
Opening a module never does anything at runtime. It just puts all the symbols in the opened namespace in scope for unqualified access below the open statement.
Section 12.5 of the language spec is what you want to read - this details when the static initialization of a module will run.
Given that, the only time when this initialization is run automatically, as far as I know, is for last module in an exe.
I.e. I don't think there is a direct way to accomplish what you want.
If you have reflective access to the module:
ModuleType.TypeInitializer.Invoke(null, null)
will invoke the static initialization.
You can add the AutoOpen attribute to the module
[<AutoOpen>]
module SomeModule =
do printfn "module loading"
let x = 23
However this will only print the module loading message when you reference x.
Not sure if you found the solution to your problem but in my case I wanted to start an agent when my website was starting and it was indeed starting twice like you mentioned.
What I did was set a method let start() = inside the module and invoke the method using a static do xxx.start() from my main Site type.
Found that by reading the language spec Kurt linked.