I am new to winCE (.net 2.0) programming.
My project is in C# language. A guy before me was using log4net (Runtime version : V1.1.4322, Version 1.2.10.0). What does those versions means, Am I right V1.1.4322 means it was compiled on .net version 1.1.4322
Now the problem is if I compile it is giving me warning(s):
Consider app.config remapping of assembly "System.Data, Culture=neutral, PublicKeyToken=969db8053d3322ac, Retargetable=Yes" from Version "1.0.5000.0" [] to Version "2.0.0.0" [C:\Program Files\Microsoft Visual Studio 8\SmartDevices\SDK\CompactFramework\2.0\v2.0\WindowsCE\System.Data.dll] to solve conflict and get rid of warning.
Consider app.config remapping of assembly "System.Xml, Culture=neutral, PublicKeyToken=969db8053d3322ac, Retargetable=Yes" from Version "1.0.5000.0" [] to Version "2.0.0.0" [C:\Program Files\Microsoft Visual Studio 8\SmartDevices\SDK\CompactFramework\2.0\v2.0\WindowsCE\System.Xml.dll] to solve conflict and get rid of warning.
Consider app.config remapping of assembly "System, Culture=neutral, PublicKeyToken=969db8053d3322ac, Retargetable=Yes" from Version "1.0.5000.0" [] to Version "2.0.0.0" [C:\Program Files\Microsoft Visual Studio 8\SmartDevices\SDK\CompactFramework\2.0\v2.0\WindowsCE\System.dll] to solve conflict and get rid of warning.
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Microsoft.Common.targets : warning MSB3247: Found conflicts between different versions of the same dependent assembly.
My application .exe is OK but when I am running WinCE Emulator it is crashing
I have worked with app.config, it didn't fix my problem
any suggestions ?
The problem you're seeing is you've got references to two different versions of log4net.
Check any referenced assemblies to see if you've got references in those projects. Then confirm the versions of any copies of the file you've got on disk.
It can be a pain to find the offending file; I've found the simplest thing is to find all copies on disk, and just delete all copies of the incorrect version. Then see where your project complains and adjust.
I'm not sure that you're having just a log4net problem.
The assemblies its complaining about are normal CLR assemblies (from the System namespace). It almost seems to me that you have references to several .NET 1.1 assemblies but you've got your project set to use .NET 2.0. The IDE is asking you to map the 1.1 assemblies to the 2.0 ones so that your project will know which one it should use at runtime.
Related
Well I have a problem, we upgraded the .net framework from version 4.0 to version 4.6 of .net, I have about 9 projects running and I had to install masstransit and autofac in 2 projects, this caused some libraries to be updated or installed in other projects.
At the moment in one of the projects(Team.Services) I have installed the 4.5.2 version of the library System.Threading.Tasks.Extensions, before of this I had the version 4.2.0.0, but now I update this. The image below you can see that it is version 4.5.2.
Now when I see the references of the project I can see that I do not have the correct version referenced, it is as if another dll was installed
look for the solution(link below) in other places, also try to change the version in the app.config check the version in the package.config clear the nuget cache and reinstall everything. and it is not working, it keeps looking for the old dll and for this reason it doesn't find the new dll, besides the installations seem to be a different version.
DLL hell - Could not load file or assembly System.Threading.Tasks.Extensions
This is the error:
System.IO.FileNotFoundException
HResult=0x80070002
Message=Could not load file or assembly 'System.Threading.Tasks.Extensions, Version=4.2.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' or one of its dependencies. The system cannot find the file specified.
Source=Team.Services
StackTrace:
at Team.Services.ServiceFactory.StartServices(String applicationDirectory) in C:\Users\amilkar.contreras\source\repos\TFS.TeamServices\Common\Team.Services\ServiceFactory.vb:line 110
at Team.ServiceHost.Service.OnStart(String[] args) in C:\Users\amilkar.contreras\source\repos\TFS.TeamServices\Hosts\TeamServiceHost\Service.vb:line 25
at Team.ServiceHost.Service.Start(String[] args) in C:\Users\amilkar.contreras\source\repos\TFS.TeamServices\Hosts\TeamServiceHost\Service.vb:line 34
at Team.ServiceHost.Program.Main(String[] args) in C:\Users\amilkar.contreras\source\repos\TFS.TeamServices\Hosts\TeamServiceHost\Program.vb:line 41
You can have a try the possible solution to solve it:
Confirm the Package Management is Package.config in visual studio, then reinstall this package again
delete .vs folder then restart visual studio
Remove this dll manually, then add the new dll as reference manually
As I need to import a library targeting .NET Standard 2, I had upgraded my library to .NET 4.7.1, as I understood from this MS video that should avoid this issue: https://www.youtube.com/watch?v=u67Eu_IgEMs
However, adding .NET standard now results in dozens of System.xxx references, rather than a single reference to .NET Standard (as per the video).
Worse still, several of the references have been added but the underlying file appears to be missing generating warnings, e.g.
Warning The referenced component 'Microsoft.Win32.Primitives' could not be found.
Warning The referenced component 'System.IO.FileSystem' could not be found.
Warning The referenced component 'System.Security.Cryptography.X509Certificates' could not be found.
Warning The referenced component 'System.Globalization.Calendars' could not be found.
Warning The referenced component 'System.Security.Cryptography.Encoding' could not be found.
Warning The referenced component 'System.Security.Cryptography.Primitives' could not be found.
Warning The referenced component 'System.IO.Compression.ZipFile' could not be found.
Warning The referenced component 'System.Console' could not be found.
I even re-created the demo project in video and got the same result - no single reference to .NET Standard, lots of DLL references instead.
I've tried a NUGET update-package -reinstall and downgraded and upgraded to .NET standard 2.0 and 2.0.1 as well
The answer I'm creating for my own question is:
Does your .NET Framework project use packages.config ? If it does, DO NOT reference .NET Standard libraries. The package/reference/binding-redirect in VS 2017 is horribly broken if you introduce .NET Standard. Trying to fix it will cause more problems (I've wasted several days trying). Expect to have assemblies which don't load despite being present, lots of warnings and a broken app.
If you use System.Net.Http, plan on spending several days in Google and GitHub issues trying to get that to work.
If you are able to upgrade to packageReferences, this should fix the problem. But if your project contains packages that import content, like JQuery or Bootstrap be aware that these no longer work and you'll instead spend more time trying to fix those references and migrate to npm or bower, along with fixing TypeScript compilation too. No thanks.
Ideally you'd be using the 2017 csproj format but that's not compatible with WinForms, ASP.NET or Windows Services - so tough if you've got a legacy project.
Because of some issues with the implementation of the .NET Standard 2.0 support on .NET Framework 4.7.1, additional files are required to be deployed to your bin folder.
This issue is described as a known issue here.
The number of files copied to the output folder will be 0 when you are targeting or running on .NET Framework 4.7.2.
Please also make sure you are using the latest Visual Studio (at least version 15.6.3) because some of the changes required to make this scenario work are available there.
I had an absolutely the same issue. I was trying to install Microsoft.Azure.ServiceBus package on the empty console .NET Framework 4.7.1 project and got all these broken references.
As far as I understood the root cause is https://github.com/dotnet/standard/issues/567 and the possible workaround described here https://github.com/dotnet/corefx/issues/29622#issuecomment-396753264
So I just replaced broken references like
<Reference Include="System.Security.Cryptography.Primitives, Version=4.0.1.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL">
<HintPath>..\packages\System.Security.Cryptography.Primitives.4.3.0\lib\net46\System.Security.Cryptography.Primitives.dll</HintPath>
</Reference>
in my .csproj file to
<Reference Include="System.Security.Cryptography.Primitives"/>
and it had worked because this assembly is the part of .NET Framework 4.7.1. Also I deleted all binding redirects from the .config file regarding the broken references.
Also, I've found an interesting fact. There was a reference
<Reference Include="System.Runtime.Serialization.Primitives, Version=4.1.2.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL">
<HintPath>..\packages\System.Runtime.Serialization.Primitives.4.3.0\lib\net46\System.Runtime.Serialization.Primitives.dll</HintPath>
</Reference>
and it was not broken, because this assembly exists in the .../MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net471\lib folder. So I wonder, could it be the problem of MS build?
FWIW, I was using Visual Studio 15.7.5, and was manually fixing up all of my binding redirects (to remove them). However, I noticed that my colleague had Visual Studio 15.9.4 and on the project properties screen there is now a 'Auto generate binding redirects'. I'd previously set this in the csproj manually. But, updating to VS 15.9.4 and re-building the projects got rid of all of the binding redirects for me.
I've ran into a weird problem.
I basically have my own web-stack for .NET-core which I've built into a few .dlls, and I want to reference these from another ASP CORE-solution.
VS seems to find the assemblies, where I can navigate types etc.
I can also build the project without any issues, but when IIS then runs the server I get an internal server error stating:
FileNotFoundException: Could not load file or assembly 'myDLL, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'. The system cannot find the file specified.
The referenced DLLs are in the debug-folder, and the really weird thing is that if I create a new ASP Core project in the same solution as the web-stack, I can reference and use it without any problems.
Why is this happening only when running on a project outside the web-stack's solution, and what can I do to make it runnable everywhere?
The .NET Core Tooling in VS 2017 (< 15.3 preview) / .NET CLI < 2.0 doesn't fully support referencing assemblies on disk. You need to package the library up as a NuGet package or use a project reference ("same solution"). The technical reason is that all the required assemblies and versions are resolved during compilation and written to the .deps.json file. When loading arbitrary assemblies, this might fail because either the assembly or its dependencies cannot be found (or a conflict with each other).
for load the external dll in core project, needed to:
vs 2017 with version 15.3 or upper.
Microsoft.Extensions.DependencyModel NuGet package installed in your project.
I am running into a dependency issue with MSBuild. I added a NuGet package for Microsoft.Tpl.Dataflow to a project in my solution. This is causing a build failure for a website project in the solution which references the first project. There seems to be an issue with getting the correct runtime version.
This is one of the many errors I get when building the solution with MSBuild.
C:\src\MyWebsite.metaproj : warning MSB3268: The primary reference
"C:\src\projects\ReferencedProject\bin\Debug\ReferencedProject.dll"
could not be resolved because it has an indirect dependency on the
framework assembly "System.Runtime, Version=4.0.0.0, Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a" which could not be resolved in the
currently targeted framework. ".NETFramework,Version=v4.5". To resolve
this problem, either remove the reference
"C:\src\projects\ReferencedProject\bin\Debug\ReferencedProject.dll"
or retarget your application to a framework version which contains
"System.Runtime, Version=4.0.0.0, Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a".
The confusing thing to be is that the solution builds fine in Visual Studio. Also, all the other projects in the solution build—it's only the website projects that are failing.
I have tried
Changing the target framework for the website to 4.0 (it's currently 4.5).
Adding an assembly reference to System.Runtime.dll version 4.0.0.0
I still can't get it to build. How can I fix this?
Turns out aspnet_compiler.exe (which is called by msbuild) does not look for libraries in the Facade directory at
C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.5\Facade
and as such, the website project in the solution would not compile.
I found this out from this blog post. As mentioned there, to fix the problem I copied the DLLs from the Facade directory into the v4.5 directory and everything works.
To be honest this is a less than ideal solution.
Please bear with me on this, I will try to explain as clearly as I can.
I started a new project (class library) which targets 4.5 and not the client profile 4.5.
I added a reference "System.Runtime.Serialization" and the properties indicates it's in location "C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.5\System.Runtime.Serialization.dll"
On my pc it compiles fine with a build script using msbuild.
On the buildserver which uses team city - it complains
error CS0012: The type 'System.Object' is defined in an assembly that
is not referenced. You must add a reference to assembly
'System.Runtime, Version=4.0.0.0, Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a'
The buildserver has the full .net framework installed - "dotnetfx45_full_x86_x64.exe"
The only time it will build is if I copy my version of "C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.5" to the target machine.
I have checked using this link and .net 4.5 is installed - http://myspworld.wordpress.com/2012/10/18/how-to-check-if-net-4-5-is-installed-on-a-server/
I am asking two question:
1. How does this get installed?
2. If it does find it in this location surely it should look in the GAC?
Will appreciate any help on this.
It's the Windows SDK:
The Windows SDK includes the reference assemblies, tools, headers, and libraries needed to build applications that target the .NET Framework 4.5.
(For 1.1 and 2.0, there was a separate .NET Framework SDK, but I can't find a link for any more recent versions - I don't think it's separately available)
For part 2, no. The GAC is not searched at compile time. It's only used at runtime.