I have a .NET windows service made in VB.NET in Visual Studio 2013. In this project I have some DLLs referenced and also in app.config I have others defined as dependentAssembly (I didn't make this project).
When I compile this project, dependent assemblies specified in app.config are not being copied to output directory (debug or release depending on the case).
My questions are:
What is the difference between specifying dependent assemblies in app.config and reference a DLL?
Why dependent assemblies specified in app.config are not being copied to the output directory (debug or release) when compiling?
Can I force visual studio to copy dependent assemblies specified in app.config to outut directory (debug/release) when compiling?
Here is the relevant information I found about dependentAssembly. App.config should not be used on dlls, but only with executables.
If a dll is loaded in an executable, the dll will use the configuration file of the running executable and will ignore the configuration defined for him.
If you like, you can read the configured keys using some ugly code that takes them from the configuration file for the current assembly.
What you should do is put the relevant configuration into the exe configuration file. You can checked in this link for more details.
Related
I upgraded a netcore1.1 project to the new VS2017/csproj.
In my test projects only, it added:
<PropertyGroup>
<GenerateRuntimeConfigurationFiles>true</GenerateRuntimeConfigurationFiles>
</PropertyGroup>
I did some digging to discover that it generates these files in the bin directory:
ProjectName.Tests.runtimeconfig.json
ProjectName.Tests.runtimeconfig.dev.json
What is this setting and these files, and why do I need them?
Why were they only generated for my test projects?
These are specific to .NET Core projects and specify
Which runtime and version to use. Typically Microsoft.NETCore.App. The "host framework resolver" looks for a matching folder inside the shared folder (e.g. C:\Program Files\dotnet\shared\Microsoft.NETCore.App\1.1.2). This is important since multiple runtimes can be installed side-by-side and the host needs to know which one to use when you run dotnet myapp.dll.
Additional options for the runtime. The most prominent is probably the garbage collection setting that switches between "desktop" and "server" mode. When you set <ServerGarbageCollection>true</ServerGarbageCollection> int he csproj file, this will cause a value in the runtimeconfig.json to be set. (This property is defaulted to true for web projects)
Additional options for the host. additionalProbingPath for example is set to your local NuGet cache which contains the restored packages. You may have noticed that referencing a NuGet package does not cause its dll files to be copied to the output directory (by default). The host uses the additional probing path to look for packages / dlls referenced to in this location (actually it is a two-step lookup: deps.json tells the host which packages to use and this property tells where to look for this package). Since this is only used for development and shouldn't end up in the published output (since this would mean relying on a NuGet cache on the target), this settings is put into a runtimeconfig.dev.json.
"Classic" .NET Framework projects also had a concept of letting the application set some runtime settings. This was accomplished by having an .exe.config file (which would be built from an App.config file in a project if present). You can think of runtimeconfig.json as "the new .exe.config" but the only have a few overlapping concerns.
I have old project that uses WCF from withing C# CLR triggers for SQL Server. I was always installing it by running a script.
But I've decided to move on to SSDT project on VS 2012. I've imported project from empty database.
WCF functionality depends on several assemblies from .net framework
SMdiagnostics
System.Web
System.Messaging
system.identitymodel
system.identitymodel.selectors
microsoft.transactions.bridge
System.ServiceModel
So I have a reference to these dlls in my project. I also had them added to my project under Assemblies sub folder.
However when I create a deployment script, these assemblies are not in it.
So when I try to publish script to database I receive an error.
Assembly 'system.servicemodel, version=3.0.0.0, culture=neutral, publickeytoken=b77a5c561934e089.' was not found in the SQL catalog.
If I try to create custom script to add assemblies to db :
create assembly [SMdiagnostics]
from 'C:\Windows\Microsoft.NET\Framework\v3.0\Windows Communication Foundation\SMdiagnostics.dll'
with permission_set = unsafe
go
I receive error
Error: SQL70502: The assembly source is not valid. Only binary literals are allowed.
How can I add assembly from .NET to be deployed along with my SSDT project?
Thanks.
To add a .NET assembly to a SSDT project:
In Solution Explorer, expand the project and right-click References.
In the Add References window, either browse for the assembly or choose from the Assemblies category.
Right-click on the added assembly and click Properties.
Make sure these properties are set:
Generate Sql Script: True
Model Aware: True
Permission Set: Safe/External/Unsafe (depending on the assembly)
Press F5 to deploy to LocalDB/Debug destination or choose Publish and Generate Script to verify the changes.
DACPACs (the result of a SSDT build) doesn't allow CREATE ASSEMBLY with paths because the DLL isn't included and the path can't be guaranteed on another host. Therefore only embedded binary literals are allowed in the DACPAC.
How can you check GAC assembly details Windows Server 2012? I managed to register a DLL via Powershell, now I need to verify that it is really done.
You are probably looking for the custom look of the GAC directory that you were familiar with in .NET versions prior to 4.0. Which stored the GAC in the c:\windows\assembly window and used a custom shell extension to flatten the directory structure into a list of assemblies.
The shell extension is no longer used for .NET versions 4.0 and up. You have .NET 4.5 on that machine, its GAC is stored in c:\windows\microsoft.net\assembly. You just get to see the actual directory structure. Locating the assembly isn't that difficult, start in the GAC_MSIL directory and you should have no trouble locating your assembly there by its name. Locate the folder with the same display name as your assembly. It will have a subdirectory that has an unspeakable name that's based on the version and public key token, that subdirectory contains the DLL.
If your assembly is a mixed-mode assembly created with C++/CLI then you'd start from either the GAC_32 or GAC_64 directory.
just try with this path
C:\Windows\Microsoft.NET\assembly
An option would be to use PowerShell. I've created a PowerShell module which allows you to see and manipulate the GAC contents. You can find it here.
# Show the assemblies in the GAC, including the file version
Get-GacAssembly SomeCompany* | Format-Table -View FileVersion
The gacutil.exe has a parameter to do this. If you run
gacutil.exe /l
You will get a list of registrations.
I have a VS2010 SL4 project which uses an external Silverlight DLL. The project is localized with multiple RESX files, and the DLL is, too. I usually include external DLLs in my solutions as follows:
1) create a set of virtual folders in my solution like (say the imported DLL is named Sample.dll):
/Lib/Sample/Debug
/Lib/Sample/Release
2) create the same folders structure in the file system and copy under Debug and Release the respective versions of the DLL, so that now I find the following files:
/Lib/Sample/Debug/Sample.dll
/Lib/Sample/Release/Sample.dll
3) add to all the client projects in the solution a reference to /Lib/Sample/Debug/Sample.dll.
4) open the .csproj file of each project with the added reference, and change the Debug part of the path with $(Configuration), so that the right Debug/Release version is picked during build.
Now the question is: in my SL4 solution I can follow the same procedure for importing the language-neutral DLL. But what about its satellite resources? For instance, the French version of the imported DLL is built under subfolder fr-FR and named Sample.resources.dll. How should I include it correctly? Even If I try to manually add it in the compiled XAP under folder fr, it is ignored and the application falls back to its neutral culture...
I think I found it, here's a recap for whom may be interested:
open the .csproj file and ensure you add all your desired languages (separated by semicolons) in . For instance, if you support fr-Fr add <SupportedCultures>fr-Fr</SupportedCultures>.
(had to do this manually, I supposed 1. should be enough): once compiled, open your xap (rename it to .zip and open) and add if not present an element like <AssemblyPart Source="fr-FR/Sample.resources.dll" /> for each imported satellite with resources.
Thanks anyway!
We have a 32 bit mixed C/C++ application that we are trying to deploy to the world.
It naturally uses C and C++ runtime DLLs. We are using VS 2005.
The manifest constructed by VS2005 is the following:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<dependency>
<dependentAssembly>
<assemblyIdentity type="win32" name="Microsoft.VC80.CRT" version="8.0.50727.42" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
</dependentAssembly>
</dependency>
</assembly>
We ship this as a file in the same directory as the "application", named
(changed to protect the innocent) "application.exe.manifest".
On the face of it, it is sort of reasonable. But, in installing on some
systems, we get the message when "application.exe" is launched:
This application has failed to start because the application configuration is incorrect
One way to cure this is to run VCRedist_x86.exe from MSDN. (Unfortunately,
while we can run it, we don't know exactly what it is doing.
It appears to be parking DLLs in the SxS directories. But what else
does it do?)
a) The MS docs seem to indicate that the assembly must have an assemblyIdentity
tag directly underneath the assembly tag, that names the application itself.
This is clearly missing here, but the manifest seems to partially work in that
if we remove it, the application doesn't start even if the DLLs are present.
b) Remarkably the assembly doesn't mention the C runtime DLL. Do I need to just add that by hand?
c) We dont want to be dependent on whether the right version DLL is present on the target machine. Assuming that the assembly makes it clear which DLLs to use, how is that we can ensure the DLLs we need are on the target system? (In particular, we don't want run VCRedist or ask our customer to do this). Before assemblies came along, we solved this problem by simply placing the C and C++ DLLs in the same directory as the application .exe file, and Windows would look there first to pick them up. Can we still ship the C and C++ DLLs in the same directory? I can't figure out from the MS docs I can find how the SxS finds the appropriate dependent assemblies.
Any help appreciated.
a) The manifest xml validation clearly has some problems. Depending on the version of Windows this may or may not be an issue. Since so many applications don't correctly follow the schema (and because it was never properly enforced), I doubt it will ever be strict here.
b) The C runtime DLL is referenced in the Microsoft.VC80.CRT.manifest file, pulling it in to to the loader dependency graph. Providing you have a dependency on the manifest, you will also implicitly have a dependency on the DLL.
c) Per my earlier comment, the correct thing to do (aside from installing the latest redist system wide) is to put the CRT manifest and all three DLLs in your application directory. This is poorly documented under SxS: Private Assemblies and Installing Side-by-side Assemblies as Private Assemblies. The probe order is defined in Assembly Searching Sequence.
Generally a SxS binding failure will put an entry in the Application (for Vista+) or System Event Log (pre Vista) describing the error.
Activation context generation failed for "C:\TEMP\sxs\PEVerify.exe".Error in manifest or policy file "C:\TEMP\sxs\Microsoft.VC90.CRT.MANIFEST" on line 4.
Component identity found in manifest does not match the identity of the component requested.
Reference is Microsoft.VC90.CRT,processorArchitecture="x86",publicKeyToken="1fc8b3b9a18e3b",type="win32",version="9.0.21022.8".
Definition is Microsoft.VC90.CRT,processorArchitecture="x86",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="9.0.30729.1".
Please use sxstrace.exe for detailed diagnosis.
You can use sxstrace.exe in (Vista+) to see what the loader is actually doing. Junfeng covers this in more detail in Diagnosing SideBySide failures.
To get a better understanding of what is happening at runtime (after the manifest has been parsed and dependencies located), enable "Show Loader Snaps" for your image file (just the filename and extension, do not enter a directory name, like so: "notepad.exe") using gflags.exe. Run your application under windbg (Visual Studio's debugger may also work) and look at the output. Make sure to disable loader snaps when you're done debugging since it will slow down the application even when no debugger is attached. Sample output looks like this:
2d6c:36b4 # 1246428223 - LdrpHandleOneOldFormatImportDescriptor - INFO: DLL "C:\Program Files\Microsoft SDKs\Windows\v6.1\Bin\PEVerify.exe" imports "MSVCR90.dll"
2d6c:36b4 # 1246428223 - LdrpMapDll - INFO: Mapping static redirected DLL "C:\Windows\WinSxS\x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.4148_none_5090ab56bcba71c2\MSVCR90.dll"
ModLoad: 4fbd0000 4fc73000 C:\Windows\WinSxS\x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.4148_none_5090ab56bcba71c2\MSVCR90.dll
2d6c:36b4 # 1246428285 - LdrpMapDll - INFO: Mapped DLL "C:\Windows\WinSxS\x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.4148_none_5090ab56bcba71c2\MSVCR90.dll" at address 4FBD0000
2d6c:36b4 # 1246428285 - LdrpHandleOneOldFormatImportDescriptor - INFO: DLL "C:\Windows\WinSxS\x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.4148_none_5090ab56bcba71c2\MSVCR90.dll" imports "KERNEL32.dll"
You could link the C/C++ runtime statically.
You can change the library linkage in the C/C++ compiler options in the Code Generation section. Change the entry from Multithreaded [Debug] DLL to Multithreaded [Debug].
Your DLL will then contain the required parts of the runtime, and the separate installation is not required.
I've never understood how the manifest stuff all hangs together ... but instead of placing the C runtime DLLs in the same directory as your exe try copying the whole 'Microsoft.VC90.CRT' folder from the redist folder in the Visual Studio install (C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\redist\x86\Microsoft.VC90.CRT on my machine).
I believe Microsoft encourages the use of shared libraries and running the official redist since it installs the libraries 'properly' and means they can patch security issues that may be found in them.