I am new to Visual Studio, so please be patient.
I am working on a product that depends on a dll file that is provided by a third party. We will call them OtherCompany.dll. We do not distribute this.
Our product contains a dll file that is dependent on OtherCompany.dll. We will call it MyCompany.dll. When we build MyCompany.dll, we are currently building against version 1.0.0 of OtherCompany.dll. However, we recently discovered that OtherCompany.dll changed its version to 2.0.0. There were no changes to existing functionality, only additions.
Some users purchased OtherCompany.dll version 2.0.0 and now our product breaks as version 1.0.0 is not in the GAC. I understand this is a common issue, and I have been trying to discover a good solution.
I attempted to add into my .csproj file for our MyCompany.dll and building against OtherCompany.dll version 1.0.0, and install it on a machine with OtherCompany.dll version 2.0.0. It is still failing with the error
Could not load file or assembly 'OtherCompany, Version=1.0.0, Culture=neutral, PublicKeyToken=1234' or one of its dependencies. The system cannot find the file specified.
I understood that would allow MyCompany.dll to be version independent of OtherCompany.dll. What did I do wrong or misunderstand ?
I was able to get things to work by manually adding into the products .config file, but this is cumbersome and I would like something that would continue to work, in case next week OtherCompany.dll releases version 3.0.0.
Related
I have a vsix project. I use commandtool and create files. I upgraded .net framework (4.6.1 to 4.7.2) and packages
I run project, everything is ok. But I get error when I click Extension's button.
I checked error in XML file. Error description is
Description: Could not load file or assembly Microsoft.VisualStudio.Threading, Version=16.8.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a; or one of its dependencies
But there is package in References
Do you have any idea?
Best Regards
When you upgraded to the newer version of Microsoft.VisualStudio.Threading, you upgraded to a version that's higher than what your Visual Studio is shipping with as a part of the platform. Although there are ways you could make your version now be the preferred version, the easiest answer is probably 'don't do that', since you're artificially limiting which versions of VS your extension could install onto.
Unless you had a specific reason to upgrade, you're probably best off leaving the version there.
I have encountered this error when I am adding the DAI.dll to the assets folder.
this error happens when I try to build.
UnityException: Failed to run reference rewriter with command --target="Temp\StagingArea\DAI.dll" --additionalreferences="Temp\StagingArea","C:\Program Files (x86)\Windows Kits\10\UnionMetadata\10.0.17134.0\Facade","C:\Program Files (x86)\Windows Kits\10\References\10.0.17134.0\Windows.AI.MachineLearning.Preview.MachineLearningPreviewContract\1.0.0.0","C:\Program Files (x86)\Windows Kits\10\References\10.0.17134.0\Windows.ApplicationModel.Calls.CallsVoipContract\3.0.0.0","C:\Program Files (x86)\Windows Kits\10\References\10.0.17134.0\Windows.ApplicationModel.SocialInfo.SocialInfoContract\2.0.0.0","C:\Program Files (x86)\Windows Kits\10\References.....(followed by alot more of this)....
I am using visual Studio 2017 version 15.7.3 and Unity version 2017.2.0b7
I have added the DLL to the assets folder in unity.
These are my player and build settings.
You need to change the settings in unity (Settings example in the photo below):
Find your dll file in your project inside Unity.
Click on it once to highlight it.
You will see the dll options in the Isnpector
Usually for HoloLens, you only select "WSAPlayer"
Click Apply to save settings.
Rebuild
Warnings
Sometime the dll that you trying to include is referencing something else is not included and that's why it will not work, but the error will be different than what you got.
Sometimes you may need to import an older version of the DLL. For example, I tried to import Newtonsoft.Json 11.0.2, but 11.0.2 was referencing a newer core framework than the solution that unity generate. There is a way to update it, but I didn't want to deal with it every time, so I found out that the highest version that I can use is 9.0.1 (I had to skip 11.0.2, 11.0.1, 10.0.3, 10.0.2, 10.0.1).
Also, keep in mind that you should include netstandard dll.
I usually have UWP test project in hand to try to test my dll with it. If it works there, then it is a good first step that it may work after importing it to Unity assuming it does not have dependencies.
Last result workaround
You can comment the code that references your dll
build the project from unity without the dll
in the generated UWP solution, you can add dll normally and even use nuget to install your desired dll
Uucomment your code.
Build your solution then deploy to your device or create a package to deploy it to device or store.
This works nicely as a work around.
One issue with this is that you will need to import dll or install nuget every time solution generated if it was deleted. It gets annoying and if you are working with a team, it can get confusing when they get the project and think that it does not work. Meaning you need to do more work to communicate and deploy.
Second issue, Unity is moving away from .NET backend to IL2CPP (I don't think you can do this in the CPP generated project). Meaning this is a short term workaround.
Consider upgrading to Unity 2018.2
Using .NET 4.X instead of .NET 3.4 Equivalent made my life easier with references and issues related to references and using more modern C# code.
You can install it and still keep the 2017 version if you install Unity Hub. This will minimize the risk of considering the update.
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 am trying to generate help files using Sandcastle, locally this works find but on my build server I keep receiving the same error message:
SHFB: Error BE0073: A project with a different or higher framework version was
found but that version (.NETFramework 4.5) or a suitable redirected version
was not found
I have checked and I have .NET 4.5.1 installed and 4.5, my projects build without an issue on the server. It is only Sandcastle that is causing a problem.
Does anyone know the cause of this error or how I can diagnose it further?
For some reason the directory:
C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5
Was missing on my build server. I copied it from my local machine and everything started to work.
I was experiencing the same issue trying to configure VSTS.
SHFB: Error BE0071: Unable to locate information for the project framework version '.NET Framework 4.6.1' or a suitable redirected version on this system. See error number help topic for details.
The LastBuild.log showed that it was not finding the .NETFramework folder.
Finding tools...
The Sandcastle tools are located in 'd:\a\1\s\packages\EWSoftware.SHFB.2017.1.28.0\Tools\'
The SHFBROOT system environment variable was not found. This variable is usually created during installation and may require a reboot. It has been defined temporarily for this process as: SHFBROOT=d:\a\1\s\packages\EWSoftware.SHFB.2017.1.28.0\Tools\
Locating components in the following folder(s):
d:\a\1\s\Documentation\Project.Docs
C:\ProgramData\EWSoftware\Sandcastle Help File Builder\Components and Plug-Ins\
d:\a\1\s\packages\EWSoftware.SHFB.2017.1.28.0\Tools\
Last step completed in 00:00:00.0360
I ended up setting the Project-specific components path in the project properties to point to the SHFB .NET Framework package and this solved the problem.
For me this message occurred after I had installed the Sandcastle Help File Builder application on our build server, but the build logs were complaining that the SHFBROOT environment variable wasn't found, but I had configured an override in the Help File Builder project which the build log said it would use instead.
<PropertyGroup>
<!-- NOTE: Update the version number in the path (YYYY.M.D.R) to match the package version -->
<SHFBROOT Condition=" '$(SHFBROOT)' == '' ">$(MSBuildThisFileDirectory)\..\packages\EWSoftware.SHFB.2017.1.28.0\tools\</SHFBROOT>
</PropertyGroup>
The above setting didn't help me on the build server however and it was still failing (but not locally).
What did work for my case was a reboot of our build server.
A fairly obvious oversight on my part, as I expect this is somewhere in the help documentation that I may have initially missed.
I had this related issue with running it on the build server:
BE0071: Unable to locate information for the project framework version 'XXXX'
Cause
The build engine was unable to locate framework information for the version specified in the project's FrameworkVersion property. An attempt was made to redirect usage to a later version but none were found.
Solution
This can happen if you select a framework that is not installed on the system. For example, choosing an earlier version of the Silverlight framework. If the earlier version is not found, the build engine will attempt to redirect usage to a later version of the framework if one can be found on the system. If the specified version or a later version cannot be found, you will need to install the selected or later version of the framework specified in the project on the system.
The framework assemblies are searched for in the Reference Assemblies folder (%ProgramFiles(x86)%\Reference Assemblies\Microsoft\Framework). If you have not installed a version of Visual Studio related to the indicated framework version or the related targeting pack, the reference assemblies may not exist there. The simplest solution is to download and install the appropriate targeting pack or copy the reference assemblies from another system that does have them.
If using the Sandcastle Help File Builder NuGet package, it may mean that you need to install one or more of the help file builder Reflection Data Set packages which contain the necessary files. If multiple versions of the platform package exist, install the latest release as it will cover all prior releases as well. Be sure to set the project's Component Path project property to the packages folder if it is not under the help file build project folder. Once installed and the component path is set, you may need to close and reopen the project in order for it to detect the newly installed files.
My project targets .Net 4.0 Client profile but it crashes as soon as it starts by displaying a file load exception stating that System.Core version= 2.0.5.0 . How can I change that?
Edit: Forgot to add, it's a WPF project.
This is mainly for future me, who will at some point come back to this question, and none of the current answers will solve your problem (hey future me!)
My issue was a nuget package referencing System.Core 2.0.5.0 so I had no control over the reference.
To get System.Core 2.0.5.0 installed on the machine, which already had .NET 4.0 installed and patched, I installed the Portable Class Library.
To install the Portable Class Library tools on a build machine without installing Visual Studio 2012, download the Portable Library Tools, and save the download file (PortableLibraryTools.exe) on your computer. Run the installation program from a Command Prompt window, and include the /buildmachine switch on the command line.
I had a problem similar to this that only occurred on windows XP/Server 2003 while Windows 7/Server 2008 and later worked fine. After a long time of looking I ran into this article:
http://code.google.com/p/autofac/wiki/FrequentlyAskedQuestions
It suggested downloading the following hotfix
http://support.microsoft.com/kb/2468871
After installing that everything worked fine! Maybe give that a try and see if it helps.
Probably you included reference to some libraries belonging to .Net 2.0 and they depends on System.Core 2.0. So you need to check every reference's version number included in your project.
Make sure that System.Core in References targets version 4. Also, make sure Specific Version is false. You could also try to remove the reference to System.Core and then add it again.
Open the references section in solution explorer, delete the System.Core
Right click on the References and add a new one, locate System.Core v4.0 and add that one.
I was able to fix a similar error by installing Framework 4.0 UPDATE kb2468871
Direct link: http://www.microsoft.com/en-us/download/details.aspx?id=3556
Info Link: http://support.microsoft.com/kb/2468871