I have written a .NET 4 NT service which connects to an Oracle 11g database and now I wish to deploy.
The target machine has Oracle drivers installed but only for ODP v2. (I assume; there is only a 2.x folder in ODP.NET\Bin)
There is no upgrade path; company packages do not include what I am looking for, and I have no say in what should be included in those standard builds.
I am, on the other hand, permitted to install downloaded drivers ...
The target already runs 3 applications using the installed driver. It is a requirement that they continue to do so undisturbed.
So, with 2 sets of Oracle drivers installed, how do I ensure that my new application uses the new set whilst keeping the old set 'primary' ?
I assume both of the installers place the ODP assemblies in the GAC. If so, you can force use of a particular version.
Make sure you make a fully qualified reference in your .csproj files to the version of ODP you want to use. I don't know the specifics for the assemblies you need but here is an example of what the reference should look like in the csproj files. be sure it is Fully Qualified (has name, version, culture, publickey, architecture). And that SpecificVersion is true.
<Reference Include="ODP..., Version=4.x.x.x, Culture=neutral, PublicKeyToken=theKey, processorArchitecture=...">
<HintPath>..\..\..\lib\ODP\ODP.dll</HintPath>
<SpecificVersion>True</SpecificVersion>
</Reference>
Once compiled, this will make references in your compiled code to specific versions. At runtime, the assembly loader will look for the version you request. Use Fusion Log Viewer to trace that this is happening as expected. If not you can implement assembly binding redirect in various ways.
Take a look at these links if you need to go this route:
Redirecting Assembly Versions
How the Runtime Locates Assemblies
You need to look at side-by-side deployment, as outlined in Oracle's technetwork
If this is impossible to do, for some reason, you will have to look at segregating the application or some other solution.
Related
I want to add Dll reference of system assembliesSystem.Runtime.Caching assembly in my .net Standard 2.0 project(using VS2019). Due to some policy restrictions nuget usage is not possible so we need to add a dll reference(assuming target system has same version of .net framework installed),
How can add this reference so that it works in different systems without using path?
I tried following without any success:
Adding with reference manager dialog. This adds hint path(relative) which might not work in some systems(or when directory is changed).
Adding <PackageReference> adds nuget package which is restricted hence can not be used.
Tried adding override to Microsoft.Common.targets as
<AssemblySearchPaths Condition=" '$(AssemblySearchPaths)' == ''">{GAC}</AssemblySearchPaths> in csproj so that GAC is searched first.
Note: Third party package management or nuget local feed is not being accepted.
Also msbuild.common.targets file has {TargetFrameworkDirectory} option for resolving assemblies, so I tried adding <Reference Include="System.Xml"> to check if msbuild would search in target framework binaries but I still get same error.
In old style .net framework csproj structure(not SDK style) Adding something like <Reference Include="System.Xml"> used to work at runtime and compile time both, but it does not anymore.
Does DLL reference as mentioned above does not work in .net standard and core anymore?
You don't want to fight with current .NET/MSBuild architecture and NuGet. If you cannot create a local NuGet server you need to provide your path to libraries on your own. MSBuild is smart enough to find packages but if you will not provide any feed he will not resolve all of them. Under the hood, MSBuild has hardcoded paths that search for libraries as a fallback but these paths change over time when the framework evolves.
.NET Framework isn't equal to .NET Core, it's the standalone solution not related to Windows anymore so you shouldn't assume it will work as the previous framework.
Only one stable solution is to include all libs inside the project folder.
Reference still works but you need to supply a path like that(otherwise MSBuild probably will struggle to find libraries):
<ItemGroup>
<Reference Include="lib\$(TargetFramework)\*.dll" HintPath="%(FilePath)" />
</ItemGroup>
I think you should speak with your client and tell him he needs a more robust solution than fighting with a chosen framework because it's detrimental for him and you.
I've noticed that Visual studio looks for a referenced dll anywhere (other projects, GAC, ...) if that dll isn´t in referenced path. It happens mostly with nugget packages.
Is there anyway to prevent this behavior?
I think this behavior is dangerous, because it gives you false security that your application has all refenreced dlls correctly, at the time of deploy app you can get a surprise.
Thanks
The .Net Framework does look in the applications directory or subdirectories, GAC and (if deployed to) on http server.
You can find the description here.
For GAC and http server the framework does require a strong name signing. So if your assembly is not strong signed the framework won't search there.
When deploying an app with release, this normally also should include a test installation on a non-development workstation (where no visual studio or anything else is installed). Additionally, checking that all dependent assemblies are deployed is another task of programming (at least, in my opinion).
Visual studio also does copy referenced nuget packages assembly to the output directory without any manual action.
What you're describing is not a behavior of Visual Studio but rather of .NET itself. The process of how and where assemblies are resolved is an intrinsic and essential part of the technology. So in my eyes, you are contradicting one paradigm of .NET.
However, you can use a couple of workarounds. This post contains Microsoft's description of how the .NET runtime locates assemblies. Thus you could try to ship around these manners, e. g. not signing assemblies would skip accessing the GAC.
I'm in C# in Visual Studio running 2015 Update 3.
I'm using a dll that I made myself for the backend of a system, and in the references of the project, one shows the "System" as Version 2.0.5 and the project being used as a dll shows it as 4.0.0. I believe this is the cause of a conflict that is preventing me from running this app. How do I update just the system version or even specify it so I can make them the same?
I think you should go to the references of your project containing the old reference, remove System and add it with version 4.0.0.0. However, you should also check that target .NET framework versions match (maybe the older dll is obtained compiling against .NET framework 2.0 and the newest one against .NET framework 4.0).
In order to find out the cause that is preventing you from running the application (you should provide what is happening), an useful tool is Assembly Binding Log Viewer which will show the exact assemblies that the application is trying to load (fully qualified assembly names).
I have ConsoleApplication01, ConsoleApplication02, ConsoleApplication03 and using "Mydll.dll" for accessing database.
I want to keep all "exes" of all Console Applications in one folder to run using windows service. So problem is that, Its asking to replace "Introp.Mydll.dll" into my destination folder.
Will it work by Replacing this file "Introp.Mydll.dll".
If its exactly the same dll (same binary) than there is no problem.
If you are using different versions for each application (and there is a good chance you should, or at least be able to, to allow upgrading the version only for a single service), you can use GAC mechanism.
GAC is sort of a centralized storage of a lot of dll's used by .net, and its uniqueness is that you can publish a lot of dll's with the same name that will have different versions or different globalization culture. That way your C# services will find the dlls and load them automatically from GAC, and if you will require to upgrade the dll just for one service, you will only change this reference to point to the new specific version.
You can read about GAC here:
https://msdn.microsoft.com/en-us/library/yf1d93sz(v=vs.110).aspx
and how to install assembly (dll) into GAC here:
https://msdn.microsoft.com/en-us/library/dkkx7f79(v=vs.110).aspx
I installed the Remote Server Administration Tools for Windows 8.1 (http://www.microsoft.com/en-gb/download/details.aspx?id=39296) expecting that this would populate the GAC with the Microsoft.GroupPolicy assemblies.
The tools themselves installed successfully, however the expected assemblies are not in the GAC.
I have repeated the exercise with the Windows 7 tools (http://www.microsoft.com/en-gb/download/confirmation.aspx?id=7887) and those assemblies do appear in the GAC following installation.
Has anyone else experienced the same issue? If so, how did you resolve it?
You are just looking in the wrong location, the screen-shot shows the GAC for the v2 runtime. Stored in c:\windows\assembly. You however downloaded a Win8.1 program, it almost certainly uses .NET 4.5 since that's the version that's pre-installed on Win8.
Which uses a different GAC, the v4 version is located in c:\windows\microsoft.net\assembly. There is no shell extension for it that flattens the view, you can see the directories in the GAC as-is. Easy enough to navigate, the GAC structure isn't very complicated.
Of course you'll have to target .NET 4.x in your project to use these assemblies. And keep in mind that it still might favor local deployment instead of the GAC, you'll have to look in the install directory as well. I didn't try it.