Сообщение Что такое Fully Qualified Type Name ? от 30.09.2021 9:10
Изменено 30.09.2021 11:14 Эйнсток Файр
https://docs.microsoft.com/en-us/dotnet/framework/reflection-and-codedom/specifying-fully-qualified-type-namesA fully qualified type name consists of an assembly name specification, a namespace specification, and a type name.
...
IDENTIFIER naming should follow the rules for file naming. The IDENTIFIER is case-insensitive.
https://docs.microsoft.com/en-us/dotnet/api/system.type.assemblyqualifiedname?view=net-5.0Spaces are relevant in all type name components except the assembly name. In the assembly name, spaces before the ',' separator are relevant, but spaces after the ',' separator are ignored.
a wildcard character (*) can be used in the assembly name specification in the permission.
...
It is illegal to replace the left part of the name with the wildcard character (for example, *.DirectoryServices)
0x80131216Error: Assembly name contains path and/or extension.
GAC задеприкейтели.
https://docs.microsoft.com/en-us/dotnet/core/compatibility/core-libraries/5.0/global-assembly-cache-apis-obsolete.NET Core and .NET 5 and later versions eliminate the concept of the global assembly cache (GAC) that was present in .NET Framework.
Как теперь указывать полное имя сборки?
Может попробовать внутрь machine.config засунуть codeBase:
https://docs.microsoft.com/en-us/dotnet/framework/configure-apps/file-schema/runtime/codebase-element
?
Можно ли указать просто путь в файловой системе (с file:/// протоколом) ?
А можно ли сделать через .pc-файлы от pkg-config ?
А через имя пакета Nuget?
(Это я ещё не говорю про то, что там негде указать архитектуру...)
Ну ок, а через контекст это (путь и/или архитектуру) можно указать?we can set up different assembly load contexts; this lets us load different versions of assemblies into different contexts in the same application. This was not really possible before. Second, we can unload assemblies after we're done with them. Again, this is something that was very difficult to do before.
можно:
AssemblyLoadContext.Default.LoadFromAssemblyPath
но мне это никак не поможет, потому что мне нужно указать путь до сборки в конфиге:
<system.data>
<DbProviderFactories>
<add name="SqlClient Data Provider"
invariant="System.Data.SqlClient"
description=".Net Framework Data Provider for SqlServer"
type="System.Data.SqlClient.SqlClientFactory, System.Data, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
/>
</DbProviderFactories>
</system.data>
Там, где type= написано. А там нет никакого FromAssemblyPath.
https://www.codeproject.com/Articles/1194332/Resolving-Assemblies-in-NET-CoreWhen you build a .NET Core application, the compiler also produces some Runtime Configuration Files, in particular the deps.json file that includes the dependencies for the application.
https://github.com/dotnet/cli/blob/master/Documentation/specs/runtime-configuration-file.mdMyApp.deps.json file ([appname].deps.json) is designed to be processed by automated tools and should not be user-edited.
Ну и всё равно это не то, что нужно. Потому что информацию о том, где продеплоена .dll-ка, которая является Sql-клиентом,
должен предоставлять компьютер, куда приложение деплоится. А не само это приложение, даже если потом можно будет переконфигурировать...
https://github.com/dotnet/core-setup/blob/master/Documentation/design-docs/multilevel-sharedfx-lookup.mdThe exact mechanics of which version are selected are defined in the shared framework lookup document.
Ой, всё...
https://docs.microsoft.com/en-us/dotnet/framework/reflection-and-codedom/specifying-fully-qualified-type-namesA fully qualified type name consists of an assembly name specification, a namespace specification, and a type name.
...
IDENTIFIER naming should follow the rules for file naming. The IDENTIFIER is case-insensitive.
https://docs.microsoft.com/en-us/dotnet/api/system.type.assemblyqualifiedname?view=net-5.0Spaces are relevant in all type name components except the assembly name. In the assembly name, spaces before the ',' separator are relevant, but spaces after the ',' separator are ignored.
a wildcard character (*) can be used in the assembly name specification in the permission.
...
It is illegal to replace the left part of the name with the wildcard character (for example, *.DirectoryServices)
0x80131216Error: Assembly name contains path and/or extension.
GAC задеприкейтели.
https://docs.microsoft.com/en-us/dotnet/core/compatibility/core-libraries/5.0/global-assembly-cache-apis-obsolete.NET Core and .NET 5 and later versions eliminate the concept of the global assembly cache (GAC) that was present in .NET Framework.
Как теперь указывать полное имя сборки?
Может попробовать внутрь machine.config засунуть codeBase:
https://docs.microsoft.com/en-us/dotnet/framework/configure-apps/file-schema/runtime/codebase-element
?
https://docs.microsoft.com/en-us/dotnet/framework/configure-apps/file-schema/runtime/codebase-elementcodebase setting can be anywhere on the local intranet or the Internet.
Можно ли указать просто путь в файловой системе (с file:/// протоколом) ?
А можно ли сделать через .pc-файлы от pkg-config ?
А через имя пакета Nuget?
(Это я ещё не говорю про то, что там негде указать архитектуру...)
Ну ок, а через контекст это (путь и/или архитектуру) можно указать?we can set up different assembly load contexts; this lets us load different versions of assemblies into different contexts in the same application. This was not really possible before. Second, we can unload assemblies after we're done with them. Again, this is something that was very difficult to do before.
можно:
AssemblyLoadContext.Default.LoadFromAssemblyPath
но мне это никак не поможет, потому что мне нужно указать путь до сборки в конфиге:
<system.data>
<DbProviderFactories>
<add name="SqlClient Data Provider"
invariant="System.Data.SqlClient"
description=".Net Framework Data Provider for SqlServer"
type="System.Data.SqlClient.SqlClientFactory, System.Data, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
/>
</DbProviderFactories>
</system.data>
Там, где type= написано. А там нет никакого FromAssemblyPath.
https://www.codeproject.com/Articles/1194332/Resolving-Assemblies-in-NET-CoreWhen you build a .NET Core application, the compiler also produces some Runtime Configuration Files, in particular the deps.json file that includes the dependencies for the application.
https://github.com/dotnet/cli/blob/master/Documentation/specs/runtime-configuration-file.mdMyApp.deps.json file ([appname].deps.json) is designed to be processed by automated tools and should not be user-edited.
Ну и всё равно это не то, что нужно. Потому что информацию о том, где продеплоена .dll-ка, которая является Sql-клиентом,
должен предоставлять компьютер, куда приложение деплоится. А не само это приложение, даже если потом можно будет переконфигурировать...
https://github.com/dotnet/core-setup/blob/master/Documentation/design-docs/multilevel-sharedfx-lookup.mdThe exact mechanics of which version are selected are defined in the shared framework lookup document.
Ой, всё...