Skip to content
This repository has been archived by the owner on Nov 1, 2020. It is now read-only.

Getting current assembly location returns empty string #5467

Closed
Scellow opened this issue Feb 28, 2018 · 5 comments
Closed

Getting current assembly location returns empty string #5467

Scellow opened this issue Feb 28, 2018 · 5 comments

Comments

@Scellow
Copy link

Scellow commented Feb 28, 2018

            var asm = Assembly.GetExecutingAssembly();
            Console.WriteLine($"Location: {asm.Location}");

Version: 026c934

Output: Location:

Expected (.net core 2.0): Location: C:\Users\Scellow\dev\test\bin\Debug\netcoreapp2.0\test.dll

OS: Win 10 x64

@MichalStrehovsky
Copy link
Member

What do you need this information for?

After native compilation, the assembly no longer exists on the file system (all assemblies get compiled into a single EXE file). We return an empty string because it's a valid return value and better than throwing an exception (e.g. it will be an empty string when the assembly was loaded from a byte array on the CLR).

@MichalStrehovsky
Copy link
Member

The most common use cases we have seen is when people call this to get a path to the app's directory. AppContext.BaseDirectory is a better API to do that.

If you really need a name of a file that no longer exists, you could construct it with Path.Combine(AppContext.BaseDirectory, asm.ManifestModule.Name)

@Scellow
Copy link
Author

Scellow commented Feb 28, 2018

I use a library and they use that to set the working directory in a static constructor :/, i think they do that because .net core applications set the Project directory as a working directory

But thanks to your explanation i understand now, and it make sense :)

@jkotas
Copy link
Member

jkotas commented Feb 18, 2019

This can be worked around now by adding:

AppContext.SetSwitch("Switch.System.Reflection.Assembly.SimulatedLocationInBaseDirectory", true);

to Main method of the application. This will cause Assembly.Location to returns paths to (non-existent) files in AppContext.BaseDirectory.

@zgramana
Copy link

Needed to use this workaround for using Grpc.Core as it uses Assembly.Location to locate its native shared lib.

jzebedee added a commit to scorpdx/ironmunge that referenced this issue Sep 10, 2020
`Assembly.Location` will return an empty string after being wrapped into a self-contained native PE.

dotnet/corert#5467
jzebedee added a commit to scorpdx/ironmunge that referenced this issue Sep 10, 2020
* Add publish-plugins YAML stub

* Update plugin projects and build

* Remove PublishTrimmed property from plugin build script

It's currently not supported to use trimming for non-SCD apps. If the PublishTrimmed option is left in, you'll see an error like this:

```
error NETSDK1102: Optimizing assemblies for size is not supported for the selected publish configuration. Please ensure that you are publishing a self-contained app. [/home/vsts/work/1/s/src/plugins/ChronicleMunger/ChronicleMunger.csproj]
```

https://dev.azure.com/scorpdx/ironmunge/_build/results?buildId=368&view=logs&j=1cbb5fa8-227a-5271-32b9-169471ebf78b&t=ee99034a-8350-59b1-e746-a0270efb6ce5&l=45

* Fix crash on startup

`Assembly.Location` will return an empty string after being wrapped into a self-contained native PE.

dotnet/corert#5467

* Don't publish an artifact just for plugins
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants