I have a C# 4.6.2 test project that is using a set of libs in a folder, it is a collection of old version 13.0.0.x libs which on our newly install laptops appear to be missing Microsoft.SqlServer.BatchParser.dll.
Does any one know how to get this into the GAC?
Or
Where to find the DLL for download?
I have found ver 14.0.0.x and above on NuGet and tried using the 14.0.0.x unofficial NuGet packs but that is throwing up yet more errors.
Had a similar problem recently, but our issue was SqlClrProvider missing, which when fix then threw up the error you are seeing. We fixed this by jumping 14.0.0.x and 15.0.0.x and going straight to the 16.0.x.x-preview NuGet which has been working well for us in both our new dev laptops with the latest SqlServer and our old CI server.
Required a couple of small code changes, but they were very minor. I think something around ServerConnection object constructor.
https://www.nuget.org/packages/Microsoft.SqlServer.SqlManagementObjects
160.1911221.0-preview
Hope that helps.
Related
When I upgraded Oracle.ManagedDatabaseAccess.dll from v. 4.122.18.3 to v. 4.122.21.1 there are several compile errors, specifically:
error CS0246: The type or namespace name 'Oracle' could not be found (are you missing a using directive or an assembly reference?)
The reference has been added. I initially used a version-specific folder, and thinking this could cause some sort of problem, I moved it to the exact same folder where the older DLL had been successfully referenced, and there was still the problem.
This is somewhat like Similar Oracle problem, except that the linked post appears to be about Oracle.DataAccess.DLL whereas this is the managed version, Oracle.ManagedDataAcess.dll
I also have tried cleaning and "rebuild all" as well as unloading the problematic project in the solution and reloading it also, and neither helps.
As far as I can discern, both DLL's are 32-bit.
I am using Visual Studio 2019, a C#, asp.net context, and since the other Oracle.ManagedDataAccess.dll worked without special usage of a "register DLL" procedure, I'm not certain if that is needed or will help.
Is there any help for this situation?
Turns out that I needed to use .net Version 4.6.2. This locally built on my machine and everything worked. We are not ready for this so I reverted to the previous DLL, but thanks. Also, when changing .net versions, one sometimes has to load/unload projects, restart Visual studio, and make sure the saves of the project file actually "take".
Perhaps this Question and Answer will help someone else, someday.
Background: I developed a .NET Standard 2.0 Nuget package (local) for a class library with a dependency on Microsoft.Extensions.Configuration, Version=2.1.1.0. It passed unit tests and ran fine when invoked from a .NET Core 2.0 console app. However, when I added my package to an Azure Function project it caused an exception to be thrown whenever I attempted to run the azure function from the VS2017 debugger.
System.Private.CoreLib: Could not load file or assembly 'Microsoft.Extensions.Configuration, Version=2.1.1.0, Culture=neutral, PublicKeyToken=adb9793829ddae60
Question: How can I fix the problem?
Copied from OPs question:
Answer: The problem goes away when I downgraded to Microsoft.Extensions.Configuration, Version=2.0.0. in my package, republished it and then reinstalled it in my Azure Function. This seems to be another example of the packages-dependency-crisis. The Nuget package manager should have caught any dependency problems with v2.1.1 when my package was added to the Azure Function project, but it didn't so it only became apparent at runtime. This is sub-optimal.
I provide the above information in the hope that others will not waste a day tracking down the same issue. It also raises the question as to how you decide what version of a package to add. Clearly in the case of Microsoft.Extensions.Configuration adding the latest stable version isn't always the best idea.
I know this is an older question but ran into the same issue downgrading a project from 2.2 to 2.1. And removed the user of ASPNetCore.All to ASPNetcore.App. This showed me how many packages we really had to depend on, as well as this issue eventually came up. My error came from the Usersecrets retrieval. Since I was missing: Microsoft.Extensions.Configuration.UserSecrets
hope this can help someone like me who was stuck on this. Should have known it would be a missing package.
We have written a service to be deployed to Azure. This consists of a DLL with a "Worker Role" class, and an Azure Cloud Service project, as shown below:
The build steps are:
Build the ccproj in "Release" configuration.
Run NuGet "spec", then "pack" to get a .nupkg file
Deploy the .nupkg file to the Azure Cloud Service
This has been working fine for a while, until we upgraded to .NET 4.6.2 and also upgraded several other references, including System.Runtime (now v4.3.1). Now, despite the fact that we have (probably unnecessarily) added a NuGet reference to every single project in the solution, pointing to System.Runtime 4.3.1, the version of System.Runtime.dll that gets deployed is an older version, resulting in DLL hell on the service, which then fails to run. If we manually copy over the correct version of System.Runtime.dll, then everything works again.
Where is this incorrect version of System.Runtime coming from? And how do we convince the offending software/hardware to use the correct version?
UPDATE: Trail is getting warmer. On my development machine, the bin folder of the EventWorker project contains the correct version of System.Runtime.dll. But... the EventProcessor\obj\debug\EventWorker folder contains the old version! I deleted the obj folder and recompiled the project - and the old version of the DLL appears again.
Where is it coming from, and how to fix?
You have the right idea in terms of hunting down the offending DLL. Have you any dependent DLL's which could be using the wrong version? Also, when run locally does it give you the dll conflict warning in the errors window, allowing you to identify where? Take a look at your config file and see if you have a reference to the DLL version in the redirects section, update it or create a new one to point at the latest version.
Well, I fixed it, but I'm not sure why this worked. I removed the NuGet reference to System.Runtime from the EventWorker project. And now the EventProcessorRole is using the correct version of the DLL.
I'll mark this as the answer in the meantime, but if anyone can provide an explanation for this behavior, I'll give you answer credit...
I started using Thrift about a week ago. I got the latest source from SVN and built the C# library (Thrift.dll). I used the library to prototype a TCP client/server with the data types that my team will be using. This worked with no problem, I just followed the example code in the SVN repo.
Yesterday, I wanted to run the same test but over HTTP instead. I searched around online some and found out that from the time I got the code last week until yesterday patch "THRIFT-322" https://issues.apache.org/jira/browse/THRIFT-322
Was applied to the trunk. So I updated my thrift source from SVN and saw the new THttpHandler class. I rebuilt the Thrift.dll so I can use the THttpHandler class but now whenever I reference the new dll Visual Studio 2010 gives me an error at compile time: "The type or namespace "Thrift" could not be found (are you missing a using directive or an assembly reference?)". When I replace the reference with the old Thrift.dll that I have I do not get this error.
I can't figure out what I'm doing wrong, I just recompiled the Thrift.dll from the SVN source and I can no longer link to the Thrift.dll. When I first add the reference it seems like it's going to work fine. Visual Studio gives me the correct intellisense, etc. Once I try to build it's like there is no longer a reference to the Thrift.dll. Any ideas?
I also submitted this to the Thrift Users Mailing List, I just thought maybe this was more general and someone here may be able to help.
Thanks,
-Sean
Since you mentioned using VS 2010... I have seen this error/behavior sometimes when I am compiling a .NET 4.0 project and my target framework for the project is set to ".NET Framework 4.0 Client Profile" instead of ".NET Framework 4.0". So you might want to check that and see if it helps.
I had a similar problem I had to switch from '.NET Framework 4.0 Client Profile' to '.NET Framework 4.0' and it worked because a referenced dll is compiled using the '.NET Framework 4.0'
One Suggestion I have is to check for a file with 'refresh' in the extension E.g. Thrift.dll.refresh or something similar. This file is usually added on adding a refernce. Try removing this file, replace the dll and try builtign and running again.
I've installed a complete SharePoint Server (MOSS) 2007 on my dev box + the latest Visual Studio (SP1) + the latest full Windows SDK. According to the Windows Workflow Foundation page http://msdn.microsoft.com/en-us/netframework/dd980558.aspx, that is all I should need to do to be able program against the .NET Workflow APIs.
And yet, all of the projects I build from the standard Workflow templates refer to the assembly System.Workflow and VS complains that that assembly isn't available. I've searched around on my hard drive, and I can't find a file for that assembly anywhere obvious on my disk.
I do find some files that look like they might be that assembly, but they're buried down in wacky places below particular applications like they are runtime support for that app. They don't seem to be what I'm supposed to point VS at.
Can anyone tell me how to fix this problem? Do I need to install something else that I have yet to come across? Are these assemblies already on my system and I just need to know how to point VS at them? I'm stumped.
BTW: I was going to try uninstalling and reinstalling VS, but the installer fails with some very cryptic error message when I try to uninstall.
TIA for any help, and Happy Holidays to all!!!
I did a Repair using the .NET 3.5 SP1 SDK distributable, and I believe that this solved the problem. I thought at first that it didn't (as I say in prior comments) because I was looking for the files to show up in the v3.5 assembly directory. The missing files actually go in the v3.0 assembly directory. I later brought up one of the sample projects in VC and noticed that the symbols were now resolving, and sure enough, the missing .dll files were now present.
So I guess that the .NET SDK installer that ships with VS somehow didn't install these .dll files. It took doing a Repair on the SDK to fix the problem.
I'm a happy camper now!
In addition to change the target framework to 4.0, you also need to:
Add a reference to System.Workflow.Runtime
Add a reference to System.Workflow.ComponentModel
There's no assembly named System.Workflow in .NET 3.x: the WF assemblies (in 3.x) are:
System.Workflow.Runtime
System.Workflow.ComponentModel
System.Workflow.Activities
System.WorkflowServices (3.5)
You should be able to find all these assemblies in the GAC, and reference them via the Add Reference dialog, .NET tab.
It's possible System.Workflow is a (badly named) SharePoint-specific DLL, in which case, sorry, the above won't help... try the SharePoint install directory or SharePoint SDK install directory. Are the project templates you're using SharePoint templates, or the ones from File > New Project > Visual C# > Workflow?
I have a same problem, and solved it. The reason is your project's target .net framework not include this assembly (it's maybe .net 3.5 client profile or 4.0 client profile). The solution is very simple: set the target framework of your project to .NET Framework 3.5 or 4.0.
It work for me.
Please find it in C:/Windows/Assembly/GAC_MSIL
All the DLLs are Present there..
Also If U donot Find it then do the Following
Right Click Project->Application->Target Framework-> .Net Framework 4.0
It should show Up then.