Problem when trying to resolve a dependency using SearchPath.

Hello,

We are using Smart Assembly 7 to obfuscate a .Net Standard assembly. When we try to resolve a .Net Standard dependency, the tool is not able to find nestandard.dll 2.0. Using Smart Assembly 6.13 we resolved this dependency by adding a new SearchPath entry to the configuration file.

In Smart Assembly 7, we have checked that a new SearchPath element is added in the settings file when we use the option "Add a new search path" from the GUI, but this does not seem to be working to solve the dependency and the interface keeps asking us to provide other paths to find the missing assembly. This doesn't work either if we try to create the project for the assembly from the command line.

On the contrary, if we use the option "Browse" in the GUI and select the assembly to load from the same path we set using SearchPath, the dependency is solved Ok and we can complete the obfuscation process without further issues.

Our idea is to provide the extra search paths just once, and then use the command line each time we need to obfuscate a new version of our assemblies. For this reason, using the option "Browse" is not a valid solution for us. Is there anything we can try to get this working?

Thank you.

Tagged:

Answers

  • Russell DRussell D Posts: 1,324 Diamond 5
    Can you confirm the version you're using please?
    Have you visited our Help Centre?
  • ndiazndiaz Posts: 5 New member
    edited April 3, 2019 3:20PM
    We are using Smart Assembly 7.0.1.2089. Is this solved in version 7.0.2?
  • Russell DRussell D Posts: 1,324 Diamond 5
    edited April 4, 2019 9:40AM
    No.
    I would advise removing any HintPath and MandatoryPath from the project file (back it up first), and also all SearchPath references from the SA config file, then try again. If it doesn't work, please send us a log file, as it should tell us what dependencies are trying to be resolved.

    Also, do you have the .NET Core SDK installed.

    Have you visited our Help Centre?
  • ndiazndiaz Posts: 5 New member
    edited April 4, 2019 10:44AM
    Hi Russell,
    Thank you for your quick response.
    We have the following versions of the .NET Core SDK installed in our server:
    .NET Core SDKs installed:<br>&nbsp; 1.0.4 [C:\Program Files\dotnet\sdk]<br>&nbsp; 1.1.0 [C:\Program Files\dotnet\sdk]<br>&nbsp; 1.1.12 [C:\Program Files\dotnet\sdk]<br>&nbsp; 2.0.2 [C:\Program Files\dotnet\sdk]<br>&nbsp; 2.1.202 [C:\Program Files\dotnet\sdk]<br>&nbsp; 2.1.504 [C:\Program Files\dotnet\sdk]<br><br>.NET Core runtimes installed:<br>&nbsp; Microsoft.AspNetCore.All 2.1.8 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]<br>&nbsp; Microsoft.AspNetCore.App 2.1.8 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]<br>&nbsp; Microsoft.NETCore.App 1.0.5 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]<br>&nbsp; Microsoft.NETCore.App 1.0.14 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]<br>&nbsp; Microsoft.NETCore.App 1.1.2 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]<br>&nbsp; Microsoft.NETCore.App 1.1.11 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]<br>&nbsp; Microsoft.NETCore.App 2.0.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]<br>&nbsp; Microsoft.NETCore.App 2.0.9 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]<br>&nbsp; Microsoft.NETCore.App 2.1.8 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
    Also, I have tried to create a new project from scratch without any mandatory or hint path. I have removed all SearchPath references from the settings file and tried to obfuscate the library again, but it is still unable to solve the dependency to netstandard v2.0.
    I have sent you a private message with the log, as it contains sensitive information.



  • Ok its very odd that SA would think your project is targeting .net 4.0 - can you submit a support request so we can investigate this a little more?
    Have you visited our Help Centre?
  • ndiazndiaz Posts: 5 New member
    Thanks, Russell. I have submitted a support request.
  • In case it helps anyone out, it looks like the ultimate resolution for this was to update the .NET framework to 4.7.2, its not yet clear to us why though.
    Have you visited our Help Centre?
Sign In or Register to comment.