[Runtime Store] conflict with dotnet command line

[gregoireternon]

Hi,

I've set up my own runtime store with custom assembly build in dotnet standard 2.0. This work well in visual studio and my custom hosted assemblies are well executed on my dotnet 5 projects within my IDE.
Howerver, as long as my "runtime store" env variables (DOTNET_ADDITIONAL_DEPS, DOTNET_SHARED_STORE) are set, i am not able to use "dotnet" command line anymore and i get such this error:

PS C:\temp\ttep> dotnet publish
Error:
An assembly specified in the application dependencies manifest (MyAssembly.deps.json) was not found:
package: 'My.Assembly', version: '1.0.8'
path: 'lib/netstandard2.0/My.Assembly.dll'

Can you tell me the reason why "dotnet" command line will encountered this error (and not my built process)? And what are recommandations so that runtime store would apply on the running program, and not dotnet command?

Many thanks in advance for your help.

Regards,

[ghost]

Tagging subscribers to this area: @vitek-karas, @agocke, @VSadov
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Hi,

I've set up my own runtime store with custom assembly build in dotnet standard 2.0. This work well in visual studio and my custom hosted assemblies are well executed on my dotnet 5 projects within my IDE.
Howerver, as long as my "runtime store" env variables (DOTNET_ADDITIONAL_DEPS, DOTNET_SHARED_STORE) are set, i am not able to use "dotnet" command line anymore and i get such this error:

PS C:\temp\ttep> dotnet publish
Error:
An assembly specified in the application dependencies manifest (MyAssembly.deps.json) was not found:
package: 'My.Assembly', version: '1.0.8'
path: 'lib/netstandard2.0/My.Assembly.dll'

Can you tell me the reason why "dotnet" command line will encountered this error (and not my built process)? And what are recommandations so that runtime store would apply on the running program, and not dotnet command?

Many thanks in advance for your help.

Regards,

Author:	gregoireternon
Assignees:	-
Labels:	area-Host, untriaged
Milestone:	-

[vitek-karas]

The store should only apply to dotnet if it contains assemblies which are used by dotnet. Do you actually put some framework assembly (or similar) into the store?

Also out of curiosity: What is the scenario you need the store for? (It's not a frequently used feature with several pretty big limitations, so I'm trying to figure out what scenarios it does solve).

[gregoireternon]

Hi @vitek-karas ,

Well my store is built following the procedure described here:
https://docs.microsoft.com/en-us/dotnet/core/deploying/runtime-store
in a project targeted to netcoreapp2.1
In package reference, i only insert my library (in dotnet standard).
So there is no framework assembly in my runtime store...
After that, i set up my store globally (global env variables).
Regarding dotnet behavior, in my opinion, i should be able to

• disable runtime store for this command
• or simply make possible the usage of my runtime store by dotnet (why is there an error with dotnet, when my project works well?)

What do you think of that?

From my understanding, runtime store is designed to inject behavior and enhance code without having to add references inside our project (as it can be done thanks to CLASSPATH in Java). So this is a very powerful feature, since it let us to adapt a component behavior according to its hosting environment.

To answer directly to your last question, my present use case is:
We hava a lot of web app built in dotnet core, running into several different environment deployed using XLDeploy: this bring us to set up configuration token like that in our appsettings.json files:
{ "Logging": { "LogLevel": { } }, "TestValue": "{{MyXLDeployKey}}" }

On different environments, these keys (like MyXLDeployKey) are replaced at deploy time by XLDeploy, but on dev workstation, this is lot of risky work to replace all of this token to the appropriate environment.
So we have a runtime store that enhance our project's behavior, only on dev computer, adding a configuraiton provider that will seek keys into XLDeploy, then replace these key at runtime when project starts on dev host.

[vitek-karas]

I haven't played with this for a while, but I think the problem is actually not the store but the DOTNET_ADDITIONAL_DEPS - that is what effectively injects code into the app. And yes, this works on any managed app which is executed with the variable set. Since dotnet CLI is also a managed app, it influences it as well. The reason why it works from VS is that VS build is using .NET Framework to run MSBuild for lot of things and thus is not affected by this.

An alternative solution to the problem might be to use startup hook. It would also apply to all .NET processes, but this might give you more control over loading the dependencies. You would just have to specify an absolute path for the startup hook itself. In it you could then check if the process it's running in is "interesting", if not it would just do nothing. If it was interesting it would then go a load additional code or do other things.

Note that it is still problematic to set the env. variable globally on the machine even for startup hooks. As it would be loaded into any app - so if the versions don't match, it would still fail.

Currently I can't think of a robust enough mechanism which would let you globally register something which could affect any .NET app on the machine without it causing problems at least in some cases.

[gregoireternon]

Hi @vitek-karas ,

Many thanks for your answer. I tried startup hook today, and it met my needs perfectly; it is much simpler to use than runtime store I don't get problem with dotnet commands.
I will have a look on the ways to use it conveniently regarding your remarks.

Thanks again!