Comments
Sort by recent activity
In my "real" project, the original output is strong-named signed, yes. In the "test" project, no.
I'm using the same .PFX file for all three cases. (Original signed + post-signed for the "real", post-signed for the "test") / comments
In my "real" project, the original output is strong-named signed, yes. In the "test" project, no.
I'm using the same .PFX file for all three cases. (Original signed + post-signed for the "real", ...
Well, I have an update. I started a brand new project (again) for more experimenting. This time however, I checked the project property Signing >> [X] Sign the assembly, and pointed it to the PFX file.
This time the project worked. Uncheck the option and it breaks again.
Seems S/A should warn against this situation, but at least I have something to focus on now on my "real" project. / comments
Well, I have an update. I started a brand new project (again) for more experimenting. This time however, I checked the project property Signing >> [X] Sign the assembly, and pointed it to the PFX...
When you try to run the obfuscated version, does the .config file exist in the same folder as the .exe?
This has caught me a few times. / comments
When you try to run the obfuscated version, does the .config file exist in the same folder as the .exe?
This has caught me a few times.
I had this problem too. My workaround is to add some code that directly references the .dll, even though the method that does so is never called in my code. [DoNotPrune]
public static class SmartAssemblyFix
{
public static Type ForceReferenceMethod()
{
return typeof([Namespace.Of.Library].[SomeClassInLibrary]);
}
}
/ comments
I had this problem too. My workaround is to add some code that directly references the .dll, even though the method that does so is never called in my code.[DoNotPrune]
public static class...