When I add a nuget package reference via the Nuget Package Manager the installed dll references an old dll that was included in the solution directory.
I've seen this problem before in Visual Studio 2013 and it was fixable by editing the project file and changing the HintPath to the correct package location. Since upgrading to Visual Studio 2015 the HintPath is pointed to the correct package folder, so the fix no longer works.
Anyone have any suggestions on how to fix this?
I've tried searching the project for the bad dll path but can't find it. It has to be stored somewhere in the project. Sooo frustrating! Any ideas? Thanks
Update
I'm trying to reference the YouTube api dll package
Related
I want to download MTAdmob plugin from NuGet for visual studio 2022 but at the end of downloading giving this error, please someone help me how to fix it.
Could not find a part of the path
'C:\Users\PC.nuget\packages\xamarin.firebase.ios.core\8.10.0.1\lib\net6.0-ios15.4\Firebase.Core.resources\GoogleUtilitiesComponents.xcframework\ios-arm64_i386_x86_64-simulator\GoogleUtilitiesComponents.framework\Headers\GoogleUtilitiesComponents-umbrella.h'.
Did you upgrade your xamarin project to the .net6.0 or migrate it to the maui? If so, you can download the package named Plugin.MauiMTAdmob.
If you project is just a xamarin.Forms, you can download the nuget package named MarcTron.Admob which is supported for the xamarin.
I created a setup project using Microsoft Visual Studio Installer Projects (0.9.3, this is latest for Visual Studio 2019). After setup is executed it installs Nuget package assemblies that are different from the assemblies generated during build.
Why is it doing that and how can I make it to chose assemblies consistent with build assemblies?
My application is for 4.7.2 framework. Typical example is System.ValueTuple.dll (4.0.2)
Build retrieves assembly from:
C:\Users\.nuget\packages\system.valuetuple\4.5.0\lib\net47\System.ValueTuple.dll
Install retrieves assembly from:
C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.7.2\Facades\System.ValueTuple.dll
While install based on 4.0.2 creates a concern but works, when I upgrade nuget package to version 4.6 (and assembly to 4.0.3) install switches to using assembly C:\Users\vgdev.nuget\packages\system.valuetuple\4.5.0\ref\net47\System.ValueTuple.dll
If you look closer, you will notice path above has \ref folder and it contains "reference" assembly. Reference assemblies are not meant to be installed and cause errors BadImageformatException.
The build after Nuget package upgrade continues to pull packages from the correct \lib folder and application works fine. So what I want to do is to make installer work consistently with build. Any advice?
Install retrieves assembly from: C:\Program Files (x86)\Reference
Assemblies\Microsoft\Framework.NETFramework\v4.7.2\Facades\System.ValueTuple.dll
Which way do you reference that package? I can only reproduce this issue when I add reference manually.(Right-click project=>Add reference=>Browse...) If you're doing so, please remove that reference, and add that reference back by Nuget Package Manager UI.
My application is for 4.7.2 framework. Typical example is
System.ValueTuple.dll (4.0.2). When I upgrade nuget package to version 4.6 (and assembly to 4.0.3)
I can only find it with latest 4.5.0 here. And I think it contains the assembly version 4.0.3 instead of 4.0.2.
(I guess something corrupts the process when VS recognize your assembly version cause in most machines it displays 4.0.3 while in one machine, it displays 4.0.2, quite strange...)
The build after Nuget package upgrade continues to pull packages from
the correct \lib folder and application works fine. So what I want to
do is to make installer work consistently with build. Any advice?
Cause of the issue:
This strange behavior may have something to do with Setup project. I can reproduce same situation and I found this issue only occurs when I use PackageReference format to manage nuget packages in my application.(.net 4.7.2)
PackageReference format is the new nuget package manage format after VS2017. I'm not sure if the Setup project fully support for it.
Here're two suggestions which may help:
1.I found this issue only occurs when using PackageReference format. So you can try using Packages.config format in your application. And I've checked the setup project can recognize this format well.
Uninstall all PackageReference format packages, and go Tools=>Nuget Packages Manager=>Nuget Package Manager to set the Allow format selection... to true.
Clean all nuget cache and click ok. After that delete bin and obj folders, then restart VS to add those packages back using Packages.config format.
2.If you continue to use PackageReference format. Try excluding the assembly from ref folder, and manually add that from lib folder by Add=>Assembly=>Browse.
Note: Since Setup project may not fully support packageReference format projects, actually I think #1 could be more suitable for your situation. And you can create a new simple project with packages.config format to check if the issue can be resolved by Packages.config format. Hope it helps :)
It seems that the root cause of the problem is the usage of the BuiltProjectOutputGroupDependencies target by visual studio setup projects instead of the ReferenceCopyLocalPathsOutputGroup target (see PackageReferences put ref instead of lib assemblies in the output group used by VS installer projects).
The proposed workaround is to overwrite the BuiltProjectOutputGroupDependencies target at the end in the project file of your main project:
<Target
Name="BuiltProjectOutputGroupDependencies"
DependsOnTargets="$(BuiltProjectOutputGroupDependenciesDependsOn)"
Returns="#(BuiltProjectOutputGroupDependency)">
<ItemGroup>
<BuiltProjectOutputGroupDependency Include="#(ReferenceCopyLocalPaths->'%(FullPath)');
#(ReferenceDependencyPaths->'%(FullPath)');
#(NativeReferenceFile->'%(FullPath)');
#(_DeploymentLooseManifestFile->'%(FullPath)');
#(ResolvedIsolatedComModules->'%(FullPath)');
#(ReferenceComWrappersToCopyLocal->'%(FullPath)')"/>
</ItemGroup>
</Target>
I have some annyoing problem which I can't figure out. I installed Visual Studio 2017 Community on a new laptop and loaded an project I made on my old one from TFS. Suddenly some of the references can't get resolved.
So I tried to create a complete fresh ASP.NET MVC Project and download some of the assemblies that don't work in the old project by NUGET. After downloading the references don't work. I get already the warning in VS. One of those assemblies that doesn't work is for example
The referenced component 'System.Linq.Expressions' could not be found.
NUGET downloaded the assembly correctly and added the reference to the project. If I open the project file I find the entry for System.Linq.Expressions
and in HintPath: ..\packages\System.Linq.Expressions.4.3.0\lib\net463.
That file definitely exists on the file system. I also tried to change to path to an absolute one manually with same result.
I am using the newest .NET framework 4.7.2
Any suggestions what might be the problem?
We've just switched from SVN to TFS 2013, and I'm trying to set up a new gated build.
The project I'm currently working on has a couple of "referenced assemblies": DLL's it's dependent on which are fixed in place and don't have a nuget reference. As soon as I tried to compile my new build, it failed complaining it couldn't find these DLLs.
I assumed the answer was to include them in the solution somewhere. Which is fine, except that using solution folders appears to be a flaky, error-prone and rather rubbish way to fix things, as per Storing referenced Dlls in visual studio solution folder
However, that dates from 2011. Are there any better and more reliable ways of achieving this?
Don't discount the nuget option so quickly :) If there is no publicly available nuget package available you can wrap your assemblies in your own nuget package using the nuget package explorer:
https://npe.codeplex.com
Does the fact that you mention nuget mean you're already using nuget for other references? If so mdkes sensd to stick with it. Also are these reference assemblies third party or built internally?
As I add and remove references sometimes I don't always "uninstall" a package which appears like a reference. So it remains "installed" in the Nuget package explorer. It seem like I could really use something that cleans up the .csproj and the packages.config file -- is there something that does this?
This would be useful for both Visual Studio (VS) 2010 and VS 2012.
Uninstalling a package should be done as an explicit gesture.
If you want to know if a particular reference is part of a package, you can check the Path of the reference. If the hint path is something like "..\Packages\.." , you will know that the reference is part of a package.
I'm also looking for a tool to help with cleaning up the packages and at least identify unused Nuget packages for me. For now the manual way to check that a package is used or not is to uninstall the package and compile the project. If everything is still passing that means the package is not used. If things failed you can simply revert the changes in your source control system. You will need to repeat these steps for each package installed in your Visual Studio solution.