Vague Dotfuscator error on Xamarin.Android app
When running Dotfuscator on the release version of my Xamarin.Android app, I'm getting the following errors:
If I disable Dotfuscator, then everything works fine. The weird part is that it works fine on a previous version of the app. In this new version of the app, I only added a handful of Android ContentProviders and one NuGet package. Nothing else. Any ideas?
Update
So as Joe Sewel explains, the issue is not technically with Dotfuscator, but with Xamarin.Android. The system from Xamarin, while generating Java classes, is populating their names from strings pulled from the .NET Intermediary Language files without first checking if those strings can actually be used as Java class names.
In my case, the issue was caused because I had two too many obfuscated C# classes in my project. Dotfuscator was renaming one of my class to do (after going through its normal renaming cycle: ab, ac, ad, and so on). Obviously, do cannot be used as a Java class name because it's a Java reserved keyword, so it caused a syntax error in the Xamarin tools later on. Removing or having Dotfuscator ignore any two classes in my project, caused Dotfuscator not to reach the do name in its cycle, and the issue was fixed. So until this bug is fixed in Xamarin.Android, there is such a thing as obfuscating too many classes in your project.
android xamarin dotfuscator asked Nov 14 '18 at 0:02
AxiomaticNexusAxiomaticNexus
4,09312746
add a comment |
When running Dotfuscator on the release version of my Xamarin.Android app, I'm getting the following errors:
If I disable Dotfuscator, then everything works fine. The weird part is that it works fine on a previous version of the app. In this new version of the app, I only added a handful of Android ContentProviders and one NuGet package. Nothing else. Any ideas?
Update
So as Joe Sewel explains, the issue is not technically with Dotfuscator, but with Xamarin.Android. The system from Xamarin, while generating Java classes, is populating their names from strings pulled from the .NET Intermediary Language files without first checking if those strings can actually be used as Java class names.
In my case, the issue was caused because I had two too many obfuscated C# classes in my project. Dotfuscator was renaming one of my class to do (after going through its normal renaming cycle: ab, ac, ad, and so on). Obviously, do cannot be used as a Java class name because it's a Java reserved keyword, so it caused a syntax error in the Xamarin tools later on. Removing or having Dotfuscator ignore any two classes in my project, caused Dotfuscator not to reach the do name in its cycle, and the issue was fixed. So until this bug is fixed in Xamarin.Android, there is such a thing as obfuscating too many classes in your project.
android xamarin dotfuscator asked Nov 14 '18 at 0:02
AxiomaticNexusAxiomaticNexus
4,09312746
It appears that the Java Activity name is being messed up, but I can not really tell since you used an image for your error.... Do not use images for errors, copy/paste the formatted error text into your question.
– SushiHangover
Nov 14 '18 at 1:51
@sushihangover That's all it is. A very long list of Java syntax errors. No helpful messages other than the Java syntax errors. Some tool somewhere is generating invalid Java files.
– AxiomaticNexus
Nov 14 '18 at 13:41
I work for the Dotfuscator team. As SushiHangover mentioned, it looks like a problem with the Java "glue" code that references a renamed activity, which isabjudging by the error's filename. What version of Dotfuscator are you using? You can also try increasing the verbosity of the build logging to Detailed, which will indicate where in the build these errors occur.
– Joe Sewell
Nov 14 '18 at 14:44
@JoeSewell I'm using version 5.36.0.7050 and the detailed version of the build output is not of much help, I think. It's just more of the same.
– AxiomaticNexus
Nov 14 '18 at 21:45
add a comment |
When running Dotfuscator on the release version of my Xamarin.Android app, I'm getting the following errors:
If I disable Dotfuscator, then everything works fine. The weird part is that it works fine on a previous version of the app. In this new version of the app, I only added a handful of Android ContentProviders and one NuGet package. Nothing else. Any ideas?
Update
So as Joe Sewel explains, the issue is not technically with Dotfuscator, but with Xamarin.Android. The system from Xamarin, while generating Java classes, is populating their names from strings pulled from the .NET Intermediary Language files without first checking if those strings can actually be used as Java class names.
In my case, the issue was caused because I had two too many obfuscated C# classes in my project. Dotfuscator was renaming one of my class to do (after going through its normal renaming cycle: ab, ac, ad, and so on). Obviously, do cannot be used as a Java class name because it's a Java reserved keyword, so it caused a syntax error in the Xamarin tools later on. Removing or having Dotfuscator ignore any two classes in my project, caused Dotfuscator not to reach the do name in its cycle, and the issue was fixed. So until this bug is fixed in Xamarin.Android, there is such a thing as obfuscating too many classes in your project.
android xamarin dotfuscator asked Nov 14 '18 at 0:02
AxiomaticNexusAxiomaticNexus
4,09312746
When running Dotfuscator on the release version of my Xamarin.Android app, I'm getting the following errors:
If I disable Dotfuscator, then everything works fine. The weird part is that it works fine on a previous version of the app. In this new version of the app, I only added a handful of Android ContentProviders and one NuGet package. Nothing else. Any ideas?
Update
So as Joe Sewel explains, the issue is not technically with Dotfuscator, but with Xamarin.Android. The system from Xamarin, while generating Java classes, is populating their names from strings pulled from the .NET Intermediary Language files without first checking if those strings can actually be used as Java class names.
In my case, the issue was caused because I had two too many obfuscated C# classes in my project. Dotfuscator was renaming one of my class to do (after going through its normal renaming cycle: ab, ac, ad, and so on). Obviously, do cannot be used as a Java class name because it's a Java reserved keyword, so it caused a syntax error in the Xamarin tools later on. Removing or having Dotfuscator ignore any two classes in my project, caused Dotfuscator not to reach the do name in its cycle, and the issue was fixed. So until this bug is fixed in Xamarin.Android, there is such a thing as obfuscating too many classes in your project.
android xamarin dotfuscator android xamarin dotfuscator asked Nov 14 '18 at 0:02
AxiomaticNexusAxiomaticNexus
4,09312746
asked Nov 14 '18 at 0:02
AxiomaticNexusAxiomaticNexus
4,09312746
edited Nov 16 '18 at 16:36
AxiomaticNexus
asked Nov 14 '18 at 0:02
AxiomaticNexusAxiomaticNexus
4,09312746
asked Nov 14 '18 at 0:02
AxiomaticNexusAxiomaticNexus
4,09312746
asked Nov 14 '18 at 0:02
AxiomaticNexusAxiomaticNexus
4,09312746
4,09312746
It appears that the Java Activity name is being messed up, but I can not really tell since you used an image for your error.... Do not use images for errors, copy/paste the formatted error text into your question.
– SushiHangover
Nov 14 '18 at 1:51
@sushihangover That's all it is. A very long list of Java syntax errors. No helpful messages other than the Java syntax errors. Some tool somewhere is generating invalid Java files.
– AxiomaticNexus
Nov 14 '18 at 13:41
I work for the Dotfuscator team. As SushiHangover mentioned, it looks like a problem with the Java "glue" code that references a renamed activity, which isabjudging by the error's filename. What version of Dotfuscator are you using? You can also try increasing the verbosity of the build logging to Detailed, which will indicate where in the build these errors occur.
– Joe Sewell
Nov 14 '18 at 14:44
@JoeSewell I'm using version 5.36.0.7050 and the detailed version of the build output is not of much help, I think. It's just more of the same.
– AxiomaticNexus
Nov 14 '18 at 21:45
add a comment |
It appears that the Java Activity name is being messed up, but I can not really tell since you used an image for your error.... Do not use images for errors, copy/paste the formatted error text into your question.
– SushiHangover
Nov 14 '18 at 1:51
@sushihangover That's all it is. A very long list of Java syntax errors. No helpful messages other than the Java syntax errors. Some tool somewhere is generating invalid Java files.
– AxiomaticNexus
Nov 14 '18 at 13:41
I work for the Dotfuscator team. As SushiHangover mentioned, it looks like a problem with the Java "glue" code that references a renamed activity, which isabjudging by the error's filename. What version of Dotfuscator are you using? You can also try increasing the verbosity of the build logging to Detailed, which will indicate where in the build these errors occur.
– Joe Sewell
Nov 14 '18 at 14:44
@JoeSewell I'm using version 5.36.0.7050 and the detailed version of the build output is not of much help, I think. It's just more of the same.
– AxiomaticNexus
Nov 14 '18 at 21:45
It appears that the Java Activity name is being messed up, but I can not really tell since you used an image for your error.... Do not use images for errors, copy/paste the formatted error text into your question.
– SushiHangover
Nov 14 '18 at 1:51
It appears that the Java Activity name is being messed up, but I can not really tell since you used an image for your error.... Do not use images for errors, copy/paste the formatted error text into your question.
– SushiHangover
Nov 14 '18 at 1:51
@sushihangover That's all it is. A very long list of Java syntax errors. No helpful messages other than the Java syntax errors. Some tool somewhere is generating invalid Java files.
– AxiomaticNexus
Nov 14 '18 at 13:41
@sushihangover That's all it is. A very long list of Java syntax errors. No helpful messages other than the Java syntax errors. Some tool somewhere is generating invalid Java files.
– AxiomaticNexus
Nov 14 '18 at 13:41
I work for the Dotfuscator team. As SushiHangover mentioned, it looks like a problem with the Java "glue" code that references a renamed activity, which is
ab judging by the error's filename. What version of Dotfuscator are you using? You can also try increasing the verbosity of the build logging to Detailed, which will indicate where in the build these errors occur.– Joe Sewell
Nov 14 '18 at 14:44
I work for the Dotfuscator team. As SushiHangover mentioned, it looks like a problem with the Java "glue" code that references a renamed activity, which is
ab judging by the error's filename. What version of Dotfuscator are you using? You can also try increasing the verbosity of the build logging to Detailed, which will indicate where in the build these errors occur.– Joe Sewell
Nov 14 '18 at 14:44
@JoeSewell I'm using version 5.36.0.7050 and the detailed version of the build output is not of much help, I think. It's just more of the same.
– AxiomaticNexus
Nov 14 '18 at 21:45
@JoeSewell I'm using version 5.36.0.7050 and the detailed version of the build output is not of much help, I think. It's just more of the same.
– AxiomaticNexus
Nov 14 '18 at 21:45
add a comment |
1 Answer
1
active
oldest
votes
What appears to be happening is that Dotfuscator is renaming a type to do - which is safe to do for non-library .NET Framework projects, because the .NET intermediate language doesn't reserve this word. Xamarin.Android's "glue" code is then creating Java code based on the obfuscated .NET assembly's type names, and since do is a reserved word in Java, this causes Java compiler errors.
To work around the issue, you could use the Dotfuscator Community user interface to exclude the type that is being renamed.
You can use the renaming map file (e.g., DotfuscatorReportsReleaseRenaming.xml) to see the mapping between the original source code names and the obfuscated names, including with the built-in decoding tool.
I work on the Dotfuscator team, and am answering in that capacity. I've also filed an issue with Xamarin, linking to this question, regarding these errors.
answered Nov 14 '18 at 23:44
Joe SewellJoe Sewell
1,9521915
In my case, it's not just one class, but two that I narrowed down by excluding namespaces and then classes. So, why those two classes? I always assumed the obfuscated names were just recycled: aa, ab, ac, and so on. If so, then wouldn't excluding those two troubled classes simply cause the next non-excluded class in the list to acquire the "do" name? Or does Dotfuscator use the original class name as a "seed" to determine its obfuscated name? If so, can I rename the class to something that will generate a non-problematic obfuscated name?
– AxiomaticNexus
Nov 15 '18 at 0:41
@AxiomaticNexus The issue only appears to occur if the renamed type is used in the Java "glue" code, which doesn't appear to be all types in the assembly. If some other type that isn't given a Java equivalent gets nameddo, then this problem shouldn't occur.
– Joe Sewell
Nov 15 '18 at 14:07
add a comment |
Your Answer
StackExchange.ifUsing("editor", function ()
StackExchange.using("externalEditor", function ()
StackExchange.using("snippets", function ()
StackExchange.snippets.init();
);
);
, "code-snippets");
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "1"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53291247%2fvague-dotfuscator-error-on-xamarin-android-app%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
What appears to be happening is that Dotfuscator is renaming a type to do - which is safe to do for non-library .NET Framework projects, because the .NET intermediate language doesn't reserve this word. Xamarin.Android's "glue" code is then creating Java code based on the obfuscated .NET assembly's type names, and since do is a reserved word in Java, this causes Java compiler errors.
To work around the issue, you could use the Dotfuscator Community user interface to exclude the type that is being renamed.
You can use the renaming map file (e.g., DotfuscatorReportsReleaseRenaming.xml) to see the mapping between the original source code names and the obfuscated names, including with the built-in decoding tool.
I work on the Dotfuscator team, and am answering in that capacity. I've also filed an issue with Xamarin, linking to this question, regarding these errors.
answered Nov 14 '18 at 23:44
Joe SewellJoe Sewell
1,9521915
In my case, it's not just one class, but two that I narrowed down by excluding namespaces and then classes. So, why those two classes? I always assumed the obfuscated names were just recycled: aa, ab, ac, and so on. If so, then wouldn't excluding those two troubled classes simply cause the next non-excluded class in the list to acquire the "do" name? Or does Dotfuscator use the original class name as a "seed" to determine its obfuscated name? If so, can I rename the class to something that will generate a non-problematic obfuscated name?
– AxiomaticNexus
Nov 15 '18 at 0:41
@AxiomaticNexus The issue only appears to occur if the renamed type is used in the Java "glue" code, which doesn't appear to be all types in the assembly. If some other type that isn't given a Java equivalent gets nameddo, then this problem shouldn't occur.
– Joe Sewell
Nov 15 '18 at 14:07
add a comment |
What appears to be happening is that Dotfuscator is renaming a type to do - which is safe to do for non-library .NET Framework projects, because the .NET intermediate language doesn't reserve this word. Xamarin.Android's "glue" code is then creating Java code based on the obfuscated .NET assembly's type names, and since do is a reserved word in Java, this causes Java compiler errors.
To work around the issue, you could use the Dotfuscator Community user interface to exclude the type that is being renamed.
You can use the renaming map file (e.g., DotfuscatorReportsReleaseRenaming.xml) to see the mapping between the original source code names and the obfuscated names, including with the built-in decoding tool.
I work on the Dotfuscator team, and am answering in that capacity. I've also filed an issue with Xamarin, linking to this question, regarding these errors.
answered Nov 14 '18 at 23:44
Joe SewellJoe Sewell
1,9521915
In my case, it's not just one class, but two that I narrowed down by excluding namespaces and then classes. So, why those two classes? I always assumed the obfuscated names were just recycled: aa, ab, ac, and so on. If so, then wouldn't excluding those two troubled classes simply cause the next non-excluded class in the list to acquire the "do" name? Or does Dotfuscator use the original class name as a "seed" to determine its obfuscated name? If so, can I rename the class to something that will generate a non-problematic obfuscated name?
– AxiomaticNexus
Nov 15 '18 at 0:41
@AxiomaticNexus The issue only appears to occur if the renamed type is used in the Java "glue" code, which doesn't appear to be all types in the assembly. If some other type that isn't given a Java equivalent gets nameddo, then this problem shouldn't occur.
– Joe Sewell
Nov 15 '18 at 14:07
add a comment |
What appears to be happening is that Dotfuscator is renaming a type to do - which is safe to do for non-library .NET Framework projects, because the .NET intermediate language doesn't reserve this word. Xamarin.Android's "glue" code is then creating Java code based on the obfuscated .NET assembly's type names, and since do is a reserved word in Java, this causes Java compiler errors.
To work around the issue, you could use the Dotfuscator Community user interface to exclude the type that is being renamed.
You can use the renaming map file (e.g., DotfuscatorReportsReleaseRenaming.xml) to see the mapping between the original source code names and the obfuscated names, including with the built-in decoding tool.
I work on the Dotfuscator team, and am answering in that capacity. I've also filed an issue with Xamarin, linking to this question, regarding these errors.
answered Nov 14 '18 at 23:44
Joe SewellJoe Sewell
1,9521915
What appears to be happening is that Dotfuscator is renaming a type to do - which is safe to do for non-library .NET Framework projects, because the .NET intermediate language doesn't reserve this word. Xamarin.Android's "glue" code is then creating Java code based on the obfuscated .NET assembly's type names, and since do is a reserved word in Java, this causes Java compiler errors.
To work around the issue, you could use the Dotfuscator Community user interface to exclude the type that is being renamed.
You can use the renaming map file (e.g., DotfuscatorReportsReleaseRenaming.xml) to see the mapping between the original source code names and the obfuscated names, including with the built-in decoding tool.
I work on the Dotfuscator team, and am answering in that capacity. I've also filed an issue with Xamarin, linking to this question, regarding these errors.
answered Nov 14 '18 at 23:44
Joe SewellJoe Sewell
1,9521915
answered Nov 14 '18 at 23:44
Joe SewellJoe Sewell
1,9521915
answered Nov 14 '18 at 23:44
Joe SewellJoe Sewell
1,9521915
answered Nov 14 '18 at 23:44
Joe SewellJoe Sewell
1,9521915
1,9521915
In my case, it's not just one class, but two that I narrowed down by excluding namespaces and then classes. So, why those two classes? I always assumed the obfuscated names were just recycled: aa, ab, ac, and so on. If so, then wouldn't excluding those two troubled classes simply cause the next non-excluded class in the list to acquire the "do" name? Or does Dotfuscator use the original class name as a "seed" to determine its obfuscated name? If so, can I rename the class to something that will generate a non-problematic obfuscated name?
– AxiomaticNexus
Nov 15 '18 at 0:41
@AxiomaticNexus The issue only appears to occur if the renamed type is used in the Java "glue" code, which doesn't appear to be all types in the assembly. If some other type that isn't given a Java equivalent gets nameddo, then this problem shouldn't occur.
– Joe Sewell
Nov 15 '18 at 14:07
add a comment |
In my case, it's not just one class, but two that I narrowed down by excluding namespaces and then classes. So, why those two classes? I always assumed the obfuscated names were just recycled: aa, ab, ac, and so on. If so, then wouldn't excluding those two troubled classes simply cause the next non-excluded class in the list to acquire the "do" name? Or does Dotfuscator use the original class name as a "seed" to determine its obfuscated name? If so, can I rename the class to something that will generate a non-problematic obfuscated name?
– AxiomaticNexus
Nov 15 '18 at 0:41
@AxiomaticNexus The issue only appears to occur if the renamed type is used in the Java "glue" code, which doesn't appear to be all types in the assembly. If some other type that isn't given a Java equivalent gets nameddo, then this problem shouldn't occur.
– Joe Sewell
Nov 15 '18 at 14:07
In my case, it's not just one class, but two that I narrowed down by excluding namespaces and then classes. So, why those two classes? I always assumed the obfuscated names were just recycled: aa, ab, ac, and so on. If so, then wouldn't excluding those two troubled classes simply cause the next non-excluded class in the list to acquire the "do" name? Or does Dotfuscator use the original class name as a "seed" to determine its obfuscated name? If so, can I rename the class to something that will generate a non-problematic obfuscated name?
– AxiomaticNexus
Nov 15 '18 at 0:41
In my case, it's not just one class, but two that I narrowed down by excluding namespaces and then classes. So, why those two classes? I always assumed the obfuscated names were just recycled: aa, ab, ac, and so on. If so, then wouldn't excluding those two troubled classes simply cause the next non-excluded class in the list to acquire the "do" name? Or does Dotfuscator use the original class name as a "seed" to determine its obfuscated name? If so, can I rename the class to something that will generate a non-problematic obfuscated name?
– AxiomaticNexus
Nov 15 '18 at 0:41
@AxiomaticNexus The issue only appears to occur if the renamed type is used in the Java "glue" code, which doesn't appear to be all types in the assembly. If some other type that isn't given a Java equivalent gets named
do, then this problem shouldn't occur.– Joe Sewell
Nov 15 '18 at 14:07
@AxiomaticNexus The issue only appears to occur if the renamed type is used in the Java "glue" code, which doesn't appear to be all types in the assembly. If some other type that isn't given a Java equivalent gets named
do, then this problem shouldn't occur.– Joe Sewell
Nov 15 '18 at 14:07
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53291247%2fvague-dotfuscator-error-on-xamarin-android-app%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
It appears that the Java Activity name is being messed up, but I can not really tell since you used an image for your error.... Do not use images for errors, copy/paste the formatted error text into your question.
– SushiHangover
Nov 14 '18 at 1:51
@sushihangover That's all it is. A very long list of Java syntax errors. No helpful messages other than the Java syntax errors. Some tool somewhere is generating invalid Java files.
– AxiomaticNexus
Nov 14 '18 at 13:41
I work for the Dotfuscator team. As SushiHangover mentioned, it looks like a problem with the Java "glue" code that references a renamed activity, which is
abjudging by the error's filename. What version of Dotfuscator are you using? You can also try increasing the verbosity of the build logging to Detailed, which will indicate where in the build these errors occur.– Joe Sewell
Nov 14 '18 at 14:44
@JoeSewell I'm using version 5.36.0.7050 and the detailed version of the build output is not of much help, I think. It's just more of the same.
– AxiomaticNexus
Nov 14 '18 at 21:45