I'm working on converting a large WPF solution's projects to SDK style and ran into some issues.
The solution is large with multiple projects(old style) all targeting .net452 and some nugets(some made by me) installed, targeting both .net452 and .netstandard2.1
This all seems to work fine, somehow the nuget manages to install the correct version targeting .net452.
I have decided to slowly convert the projects inside the solution to SDK style targeting .net452 and .netstandard2.1 just like the nugets.
This is where the problem starts, one project was converted so far that is referenced by multiple other projects.
Localy everything seems to build and run fine, however when Azure DevOps(VS version 2019) is used to build the solution there are 2 scenarios:
The famous error message is shown:
"Error CS0012: The type 'Object' is defined in an assembly that is not referenced. You must add a reference to assembly 'netstandard, Version=2.1.0.0"
It builds fine but on app launch it crashes with:
"Could not load file or assembly 'netstandard, Version=2.1.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' or one of its dependencies. The system cannot find the file specified."
I'm suspecting that the problem is related to referencing the SDK project, it looks like that somehow it references the .netstandard2.1 instead of the .net452.
The reason this is my suspicion is that if targetframework is set to only .net452 on the referenced project everything works fine.
Google has led me to two possible solutions to tell the project what framework to use from the reference:
<ProjectReference Include="..\..\..\..\foo\foo.csproj"
AdditionalProperties="TargetFramework=net452">
<Project>{xxxxxx-xxxxxx-xxxxx-xxxxx-xxxxxxx}</Project>
<Name>foo</Name>
</ProjectReference>
and
<ProjectReference Include="..\..\..\..\foo\foo.csproj">
<SetTargetFramework>TargetFramework=net452</SetTargetFramework>
<Project>{xxxxxx-xxxxxx-xxxxx-xxxxx-xxxxxxx}</Project>
<<Name>foo</Name>
</ProjectReference>
This doesn't look like it's doing anything and the problem still persists.
At the moment I ran out of ideas and I'm here asking for help. Please let me know what I'm doing wrong or what else I can try.
I have found the problem. The issue was that I had set an output directory in AzureDevOps. When the builds for the projects were finished everything was copied there, first the .net4.5.2 target DLLs and then overwritten with the netstandard2.1 dlls. To avoid this issue in case it happens to anyone, let the compiler put the files into the root project by default and copy them afterwards wherever you want.
Related
I'm newbie to .net projects. Although I was able to code in c# & use it's frameworks, Some times I face exceptions which I really didn't get any proper resource/suggestion to modify or rectify them. Hope I would get clear this time.
The exception which I faced is as follows :
Could not load file or assembly 'Microsoft.AspNetCore.Cryptography.KeyDerivation, Version=2.2.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60' or one of its dependencies. The system cannot find the file specified.
I'm really confused with such type of exceptions. What's the reason for those & how we needs to cross check to clear those ?
Here is what I did install: "Microsoft.AspNetCore.Cryptography.KeyDerivation" from nuget console with version 2.2.0.
My installed packages list image :
The main reason for this type of error is a result of your output folder. Take a look at where your binary outputs were placed. Inside of that folder (usually your .exe or .dll output, not sure what kind of .NET project you're writing), you should also have all of your dependency dlls. In this case, the dll related to Microsoft.AspNetCore.Cryptography.KeyDerivation is missing. So when you go to run your executable, it complains "Could not load file or assembly KeyDerivation" because it couldn't find it.
To resolve this issue, double check your project's references and that there are no issues with the Microsoft.AspNetcore.Cryptography.KeyDerivation reference (what I mean is, make sure there are no yellow exclamations or other icons showing up next to this reference in your Solution Explorer). If you have any issues, remove the reference, then add the nuget package again.
I'm coming to you for help for a problem I have.
I posted the problem in the CLI of dotnet but it's been 10 days+ as of this moment of writing and I have no answer.
I have a project with some dependencies on .NET 4.5 and everything worked properly in RC1 and RC2. Now trying to move to RTM (1.0), I have an error that the project can't be made runnable because the runner can't find a specific DLL. The project compiles fine. Doing dotnet run fails
It looks for the DLL in a library that my app (site) uses, specifically XXX.v15.4, version=15.4.0.0, culture=neutral, publickeytoken=b881323kd82k.dll but it does not exist. However, XXX.v15.4.dll exists fine.
Copying XXX.v15.4.dll into XXX.v15.4, version=15.4.0.0, culture=neutral, publickeytoken=b881323kd82k.dll makes the project run.
The DLL that it's trying to load is a third party library used in a library that the app (site) uses.
Any idea of how I could make the project runnable?
Thank you!
I faced the same problem, and thought that problem lied in project.fragment.lock.json or in project.json, but in my case the problem was with incorrect project.lock.json files.
It seems like after addition of some new Nuget packages these files need to be recreated.
When i deleted these files, packages have been restored correctly, and the solution successfully built.
Hope it could help someone.
I am having this same issue and it seems like what is happening is some of the dll's are set to read-only post build. SO the next time you build they can not be built.
What I have done to solve the issue is removed all read-only settings from the root folder of my solution.
So for example, if this is your folder structure in windows:
C:\Users**yourname**\Documents\visual studio 2015\Projects\ProjectName
Right-click ProjectName and remove read-only settings recursively.
In my case this has solved the issue and I hope it helps you
I'm using VS2015 and working in a solution with numerous projects.
One project in my solution (call it "MyDllProject") is a class library targeted for .NET version 4.0. It does itself reference numerous dlls, including (in this case) System.Windows.Forms. The reference in the project file is as follows:
<Reference Include="System.Windows.Forms" />
So it is not referencing a specific version. From the properties tab, it seems it is picking up that file from the following location:
C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.0\System.Windows.Forms.dll
On my system, I have numerous other versions of System.Windows.Forms in various other subdirectories (v3.5, v4.5, v4.5.1, v4.6, v4.6.1) under the C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\ root. But it seems to me my system is getting the right one.
MyDllProject builds just fine, cleans fine, rebuilds fine and seems happy as a clam.
Numerous other projects in my solution also refer to MyDllProject and they themselves also build, clean, and rebuild just fine.
HOWEVER.... there is an old ASMX web site "project" in this solution. ASMX websites don't have project files per se.... all their project information is in the solution file. Not sure if that is relevant. Like everything else in the solution, this ASMX web site is targetted for .net version 4.0. And when I build that web site, either by building the entire solution or by just building the web site project, I get the following warning:
(0,0): warning : The following assembly has dependencies on a version of the .NET Framework that is higher than the target and might not load correctly during runtime causing a failure: MyDllProject, Version=14.0.0.0, Culture=neutral, PublicKeyToken=null. The dependencies are: System.Windows.Forms, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089. You should either ensure that the dependent assembly is correct for the target framework, or ensure that the target framework you are addressing is that of the dependent assembly.
Now everything seems to work generally in my MyDllProject, and in the ASMX web site, but I like to follow the best practices and get warnings out of my build, or at least understand them. And I don't fully understand how this warning comes about, how it comes ONLY from building this one ASMX web site, and how to get rid of it.
Thanks in advance for any insights or suggestions.
I have a very small, simple ASP.NET MVC app (MVC 4 I think. .NET Framework 4) it consists of one controller with one action serving one page.
I'm deploying it on AppHarbor, pushing it with git on my local machine, I've never had problems running it locally and it has never had build issues/errors on AppHarbour but every now and then a new build (with no relevant change in my mind) will start throwing the following error:
Could not load file or assembly 'Microsoft.Threading.Tasks,
Version=1.0.12.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or
one of its dependencies. The system cannot find the file specified.
Looking into this the top answer here sorted it, I removed the dependent assemblies listed and it worked again. But then it came back. Tried a lot of different suggestions, it has always used nuget, tried removing everything and re-installing, it started working again when I wasn't even sure what I'd changed and now it isn't working again. Today I switched it to NuGet Package Restore as outlined here but that hasn't made any difference.
I can re-deploy the last working build, what I notice comparing working/not working builds downloaded from AppHarbor is that the Web/App.configs are identical (no dependent assembly entriy for this) but the Microsoft.Threading.Tasks dlls and xmls (including Extensions and Extensions.Desktop) are not in the broken build (in the working build they appear in the root and in the bin)?
In the project the dlls are linked from the packages folder for the app and Copy Local is True, they aren't a direct dependency of the Web App but of the Google Calendar API its using.
Update
On the back of writing the answer I've looked more closely at the build logs and noticed a distinct difference between a working and not-working build.
The Microsoft.Threading.Tasks.dll is not a direct dependency, its required by Google.Apis.Gmail.v1.dll, in a working build the build log will contain (see the bottom line copying Microsoft.Threading.Tasks.dll):
\Google.Apis.Gmail.v1.dll".
Copying file from "D:\temp\voz3srsa.vhb\input\TwitterBot\packages\Google.Apis.1.9.0\lib\net40\Google.Apis.PlatformServices.dll"
to "D:\temp\voz3srsa.vhb\output\Google.Apis.PlatformServices.dll".
Copying file from "D:\temp\voz3srsa.vhb\input\TwitterBot\packages\TweetSharp.2.3.1\lib\4.0\Hammock.ClientProfile.dll"
to "D:\temp\voz3srsa.vhb\output\Hammock.ClientProfile.dll".
Copying file from "D:\temp\voz3srsa.vhb\input\TwitterBot\packages\log4net.2.0.3\lib\net40-full\log4net.dll"
to "D:\temp\voz3srsa.vhb\output\log4net.dll".
Copying file from "D:\temp\voz3srsa.vhb\input\TwitterBot\packages\Microsoft.Bcl.Async.1.0.168\lib\net40\Microsoft.Threading.Tasks.dll"
to "D:\temp\voz3srsa.vhb\output\Microsoft.Threading.Tasks.dll".
A not-working build will have a different dll in its place (see the bottom line again, Microsoft.Web.Infrastructure.dll):
\Google.Apis.Gmail.v1.dll".
Copying file from "D:\temp\0kzqakoc.4jo\input\TwitterBot\packages\Google.Apis.1.9.0\lib\net40\Google.Apis.PlatformServices.dll"
to "D:\temp\0kzqakoc.4jo\output\Google.Apis.PlatformServices.dll".
Copying file from "D:\temp\0kzqakoc.4jo\input\TwitterBot\packages\TweetSharp.2.3.1\lib\4.0\Hammock.ClientProfile.dll"
to "D:\temp\0kzqakoc.4jo\output\Hammock.ClientProfile.dll".
Copying file from "D:\temp\0kzqakoc.4jo\input\TwitterBot\packages\log4net.2.0.3\lib\net40-full\log4net.dll"
to "D:\temp\0kzqakoc.4jo\output\log4net.dll".
Copying file from "D:\temp\0kzqakoc.4jo\input\TwitterBot\packages\Microsoft.Web.Infrastructure.1.0.0.0\lib\net40\Microsoft.Web.Infrastructure.dll"
to "D:\temp\0kzqakoc.4jo\output\Microsoft.Web.Infrastructure.dll".
Looking into dlls missing in the build I found this answer but I have tried a command prompt build locally and it works fine.
Update 2
Also in trying to solve this I had noticed a comment on the build (not a warning) around reference versions:
1> Consider app.config remapping of assembly "Newtonsoft.Json, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed" from Version "4.5.0.0" [C:\Users...\packages\TweetSharp.2.3.1\lib\4.0\Newtonsoft.Json.dll] to Version "6.0.0.0" [C:\Users...\packages\Newtonsoft.Json.6.0.6\lib\net40\Newtonsoft.Json.dll] to solve conflict and get rid of warning.
1>C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets(1605,5): warning MSB3247: Found conflicts between different versions of the same dependent assembly.
Couldn't get a remapping that sorted it but did get this where adding an app.config (which makes no sense for a web app) redirect fixed it where the redirect in the web.config didn't. This did stop the build issue but made little sense.
I took this to the AppHarbor support forum as this didn't get any response here, Build succeeding but missing dll and they were very helpful and it now looks like it is resolved.
Although in Visual Studio 2012 Professional all references were marked as Copy Local True, they did not have the True tag so I added these by hand for the three libraries in question. And that was it, DLLs copied.
There are a lot of links around this discrepancy, that MSBuild needs them (although I had tried an MSBuild build and it was fine), Visual Studio doesn't insert them by default (may appear if you toggle the setting false and then true) and it manifests in not copying references-of-references.
Stack Overflow question, see highest voted answer not accepted hack
Raised with Microsoft and closed as not reproducible
Error: http://pbrd.co/1vTqOTb
I am getting an error in my XAML in my WPF project:
"Error 11 Could not load file or assembly 'NLog, Version=2.0.0.0,
Culture=neutral, PublicKeyToken=5120e14c03d0593c' or one of its dependencies.
The system cannot find the file specified. MainWindow.xaml 73 9 TestApp"
I have searched the entire solution and cant find any 'NLog'
I have tried to add the NLog dll to each of my projects in the solution but it makes no difference.
Any idea?
Turned out to be the NLog was .Net 4.0 and the project was .Net 4.5
I changed the project to 4.0 and the other dependent project to 4.0 and its working.
Thanks!
Whenever you reference another library, there's the chance they will need some other library. When you reference WPF, there are a lot of underlying libraries that get pulled up.
First, make sure that the DLLs you've referenced are set to "Copy Local = True" under their Properties. Also make sure they have the same PublicKeyToken as your error - if they're referenced by strong name (and most of .NET is) a slightly different version won't be read as the correct file.
The other thing you should consider is checking whether the DLL exists in your GAC, and manually installing it if it doesn't. This can often be the cause of such frustrating errors due to a misinstalled sdk (I once has the same issue with the Blend libraries)