MonoAndroid's System.ObjectModel is not recognized by Visual Studio 2015? - dll

I installed recently the Xamarin platform and i created a default Xamarin.Forms Shared project using VS2015 and under the Droid project References i get a yellowish icon on System.ObjectModel library as you can see...
The weird thing is that in the beginning everything compiles but when i add a Cross-Platform -> Forms Xaml Page the compiler throws error on the InitializeComponent() method call.
I tried to manually reference System.ObjectModel.dll from the path C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\MonoAndroid\v1.0\Facades without any luck. When i right-click on the properties i get this
but in the file system properties everything seems to be correct.
All the above are with the default options.
Does this happen to you or it's just me? (i tested it in two computers)
If you have any questions i will update the post after this message...


Welcome to Xamarin! It's like tap dancing your way through a field of land mines. But XAML is awesome. Here is what worked for me: update your nuget of xamarin forms, do clean build, see the error/warning, restart visual studio, do a clean, restart visual studio again, do a build, spin your chair around 3 times counter-clockwise, and voila, the error is gone. It's like magic! No need to manually much around with dlls, it will just work.


Try to delete the contain of bin folder in PCL project and android project. and clean the solution try it again.
reference: http://xamarin103.rssing.com/browser.php?indx=50717177&item=8379
user: PubuduGayan, The second option that He suggested.


I hade same problem. Adding reference from C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.5.2\Facades... didn't work me.
What worked for me was to change (Tools/Options/Project and Solutions->Build and Run) Verbosity from normal to minimal, even if system.objectmodel reference-warning is still there.
Maybe this will work for developers too who are facing same problem


I faced the same problem. Deleting the reference helped in resolving the warning since System.ObjectModel was not used at all.

Related

Visual Studio builds solution automatically on launching

I faced the problem: whenever I open my working solution Visual Studio automatically starts build. I cannot find configurations to turn off this.
It looks like that problem is in solution, because I opened another solution and build did not start automatically.

This strange behavior is not expected one for VS2019. Please try:
1.Tools=>Import and Export Settings=>Reset all settings=>No, just reset settings to reset current VS settings to default.
2.Use vs installer to repair your VS if there's something broken with IDE.
3.Extensions=>Manage Extensions=>Installed=>Tools you can disable(don't need to uninstall) some third-party extensions and restart VS to check if this issue persists. To check if this issue is about VS itself or extensions.
4.Exit VS and delete the .vs, bin, obj folders of the projects in the solution, and then clear the cache, for VS2019, the corresponding folder is 16.0 instead of 14.0. After that, restart VS.

For me, this was a Resharper setting. When I turned this off it stopped happening. I think there is also a setting for Visual Studio to do this as well, but it is off by default.

System could not be found Visual Studio 2017 ASP.NET Core project

I've installed the newly released version of Visual Studio 2017 and started a fresh ASP.NET Core project targeting .NET Core.
Out of the box, I'm getting the
The type or namespace name 'System' could not be found (are you
missing a using directive or an assembly reference?)
error. Any idea what's causing this and how to fix it?
Also, looks like there are problems with NuGet packages as well:
I also tried dotnet restore on the project through the command line and got the following error:
P.S. Kind of disheartening that you get an error in a fresh new project in the latest version of Visual Studio 2017!
UPDATE:
SDK version is v 1.0.1 -- see below:
UPDATE 2:
This is very strange. Looks like the original problem was due to NuGet package source pointing to a folder under Visual Studio 2015 folder. I unchecked it and left only nuget.org. With that my project seemed to have restored all the packages and when I started the project it loads up the standard ASP.NET page. But if I open startup.cs file, I get red squigglies all over the place but if I run the project, it works fine. What's going on here?
UPDATE 3:
I closed the project and VS 2017. I then restarted VS 2017 and opened the project and now it seems to be fine. And I'm not referencing the .NETStandard library 1.6.1 and everything seems to be working fine now.

I had the same issue in my Visual studio 2017 .Net Core application. I closed the Visual studio and re-open fixed everything.

Came across the same issue today. I had an old nuget source that no longer existed. So I went into Tools > Nuget Packet Manager and un-checked the wrong one. Hit "Ok", and then rebuilt the project, and it works great now. It seems like you stumbled onto it, but also wanted to verify that it fixed my issue, and it does.

I had the same problem, first when converting a VS2015 net core mvc web project to 2017 and then when trying to create a new core web application in 2017.
Went to Tools|NuGet Package Manager|Package Manager Settings - checked 'Allow NuGet to download missing packages' and 'Automatically check for missing packages during build in VS' and then clicked 'Clear All NuGet Cache(s)'.
Then re-built the solution - it found and loaded all the required packages and ran OK.
May not work for all cases but simple and worth a try.

Multiple closing and reopening of VS2017 fixed it for me.

I had the same issue, the solution for me was to clear the NuGet cache. Tools > NuGet Package Manager > Package Manager Settings > Clear All NuGet Cache(s)

Check the version .NET Command Line Tools in CMD, just type dotnet --info. If version is 1.0.0, then try to install latest version .NET Core SDK from here.

Find the broken project and right click, Unload, right click, Re-load. Fastest fix for me.
If you get the problem while using the CLI, try doing nuget restore instead of dotnet restore as that sometimes pulls down packages that the dotnet CLI seems to miss.

I have had the same issue with Visual Studio 2019 and .NET Core SDK 2.2.
These steps solved the problem:
Close the Visual Studio
Open the Visual Studio as Administrator
Open the Solution
Right click on Solution -> Restore NuGet Packages

I've tried all answers above. For me works only removal and adding the reference again described in the following steps:
Open 'References' under the project.
Right click on 'System' reference.
Click on 'Remove'.
Right click on 'References'.
Click 'Add Reference...'.
From right menu choose an 'Assemblies',
In a search field type 'System'.
Choose 'System' from the list.
Click 'Add' button.
IMPORTANT: Restart the Visual Studio.
'System' reference you can replace with any you need.

Try adding the following line above the other references in the csproj file
<Reference Include="netstandard" />

For me the problem was caused by my project having a custom IntermediateOutputPath. For some reason, if project_name.csproj.nuget.g.targets is not in obj subfolder of project folder, the error occurs.
Using default IntermediateOutputPath or keeping a shadow copy of project_name.csproj.nuget.g.targets in fake obj folder solves the problem for me.

This issue seems to be triggered by a myriad of reasons. Mine was caused by cloning directly from VSTS using Git Bash, my project directory had spaces in it. Git Bash changed those spaces in the path to %20. It was throwing off all the references in my project. So for anyone who tried everything else and are at their wits end, make sure %20 is not in the path.

So, I have cloned the repository from github and started getting this error.
It was my project uploaded from another machine. I later realized that I have used the materialdesign packages in my project.
I have uninstalled and reinstalled these packages and it fixed my issue.

Had the same problem. Uninstalled Application Insights from my projects using the nuget package manager. I'm not looking at that yet, I just wanted core and unit tests. Problem solved.

I also had the same problem.
The is no SDK folder under the Dependencies one. Therefore, no Microsoft.NetCore.App libraries !
To solve this problem, in Nuget manager window, install any nuget which depends on .NetCoreApp (you can install for example Microsoft.AspNetCore or BundlerMinifier.Core from the Microsoft Visual Studio Offline Packages source).
The SDK will be restored by the same time.
Once it is back, you can uninstall the previously added nuget. The SDK will remain in place.

Not quite sure in which order vs 2017 trying to resolve packages.
But my situation was following. In my VS2015 I had configured local and 3rd party source for nuget packages, newly installed version of 2017 loaded them too.
https://api.nuget.org/v3/index.json was first in list.
But vs2017 throwed an error that it can't restore .net core libraries from my another local repo.
After I unchecked all of them except https://api.nuget.org/v3/index.json, it had started to working normally.

I had this problem too, but not right now, this steps solved my problem: Choose Project -> Properties from the menu bar. In the Project properties window, under Configuration Properties -> General, make sure that Common Language Runtime Support is set to Common Language Runtime Support (/clr)

Simply opening the NuGet package manager and then the Visual Studio settings related to it - without changing anything - merely looking around, and when I closed out, the problem was gone.
This seems to be an intermittent issue that can come and go for no obvious reason.

None of the answers here worked for me so I'm posting what did work.
My errors were mostly the same as the original poster but I also had:
Error loading meta data for 'Microsoft.Extensions.FileProviders.Embedded.2.0.1'
hexadecimal value 0x1C invalid character
Every time I attempted to download a different nuget package or restore old packages I would see this error. I also saw the other errors such as:
type or namespace system could not be found
What worked for me:
opened the filepath that the error said the bad metadata was in, which for me was C:\Program Files\dotnet\sdk\NuGetFallbackFolder\microsoft.extensions.fileproviders.embedded\2.0.1
Then, I put the contents of that folder into another folder I named "hiding".
Then, I went back to the nuget package manager and tried to install a package, hoping to have the SDK restored. IOt worked successfully, and all my other errors were gone as well, and the fresh new project runs as it should!

The problem for me occurred when running my Visual Studio as Admin with a separate user-- I had created a Git Repo with the source files in the user documents of my normal account. When I created a new solution in that folder the above errors occurred. Try creating your project in a different place and see if the error still occurs.

I was facing the same issue when I created a new project (.net Core 2.2) in VS2019.In my case there was an Azure package which was creating the problem.I uninstalled it and the project started working fine.
Run mentioned below command to uninstall the package.
Uninstall-Package Microsoft.VisualStudio.Azure.Containers.Tools.Targets -Version 1.7.10

I had the same problem. I cloned a github project and this error came. So I deleted the cloned project and then I cloned the project again and it worked fine.

VB.Net build error targetting .Net 2 in VS2013 [duplicate]

My app keeps getting this error (I'm using VS 2013, VB.NET, and Windows 8.1, by the way):
Could not run the "GenerateResource" task because MSBuild could not create or connect to a task host with runtime "CLR2" and architecture "x86". Please ensure that (1) the requested runtime and/or architecture are available on the machine, and (2) that the required executable "C:\Program Files (x86)\MSBuild\12.0\bin\MSBuildTaskHost.exe" exists and can be run.
The app is for .NET 3.5 (3.5 and lower versions get me this error).
I try to run the app again. Sometimes, it works; sometimes, the error comes back.
I already tried looking up for answers at Google and the answer they gave me turned out to be: "Your build's username is too long" (they said that 20 characters or more cause the error), but it's not true. My user name is 5 characters only. Anyway, I don't think my build's username's length has anything to do with it; it makes no sense.
Does anyone know what is wrong with 3.5 and lower versions? Thank you.

This fixed the issue on my machine:
To resolve it, go to your csproj file and add the following line under the default property group:
<PropertyGroup>
...
<DisableOutOfProcTaskHost>true</DisableOutOfProcTaskHost>
</PropertyGroup>
Found here.

Clean and rebuild solution worked for me.

Adding this in each project is a cumbersome task. So you can set it in the environment variables.
Click Start>> Right-click Computer >> Properties >> Advanced system settings >> Click Environment Variables button to open the dialog, then under the System variables section, click New… button, type the Variable name = DISABLEOUTOFPROCTASKHOST, and type the Variable value = 1, then click Ok.
More here

I'm using VS 2013, VB.NET, and Windows 10, 64 bits, by the way
Just change in XML properites , Services : .NET Framework 4.6 instead .Net Framework 2.0 (Default)
and working fine for me.

I try adding the follow but didn't works
<PropertyGroup>
...
<DisableOutOfProcTaskHost>true</DisableOutOfProcTaskHost>
</PropertyGroup>
this solve this issue for me, adding the same as enviroment Variable
DisableOutOfProcTaskHost=true

I encountered this error when trying to build a sample solution that was included in some software that was installed under C:\Program Files\. Visual Studio prompted me to restart with elevated privileges (as it does when opening a solution in a "secure" location), however the build failed with the OP's error message.
Copying the solution to a "normal" folder (e.g. C:\Temp) solved it for me.

I tried opening an old VS2010 vb project inside VS2013 recently and just ran into this problem. I got around it this way:
I went to the vb project's properties page
I clicked the "Debug" tab
In the "Enable Debugers" section, I saw that the "(x) Enable the Visual Studio hosting process" checkbox was already checked.
I tried un-checking the "( ) Enable the Visual Studio hosting process" option
I saved these changes (Ctrl+S)
I then checked the "(x) Enable the Visual Studio hosting process" checkbox once more
I saved these changes (Ctrl+S)
My next re-build of the project was then successful.
Luckily, I was able to observe how the .vbproj file changed in my version control, and saw that it added the following line into it (which was not there before, despite the checkbox already being set initially):
<UseVSHostingProcess>true</UseVSHostingProcess>

None of the answers in this worked for me. I had to run Visual Studio as admin. Hope this helps someone in the future!
If you don't know how to run a program as admin on Windows, click this link.

"GenerateResource" task CLR2 runtime error

My app keeps getting this error (I'm using VS 2013, VB.NET, and Windows 8.1, by the way):
Could not run the "GenerateResource" task because MSBuild could not create or connect to a task host with runtime "CLR2" and architecture "x86". Please ensure that (1) the requested runtime and/or architecture are available on the machine, and (2) that the required executable "C:\Program Files (x86)\MSBuild\12.0\bin\MSBuildTaskHost.exe" exists and can be run.
The app is for .NET 3.5 (3.5 and lower versions get me this error).
I try to run the app again. Sometimes, it works; sometimes, the error comes back.
I already tried looking up for answers at Google and the answer they gave me turned out to be: "Your build's username is too long" (they said that 20 characters or more cause the error), but it's not true. My user name is 5 characters only. Anyway, I don't think my build's username's length has anything to do with it; it makes no sense.
Does anyone know what is wrong with 3.5 and lower versions? Thank you.

This fixed the issue on my machine:
To resolve it, go to your csproj file and add the following line under the default property group:
<PropertyGroup>
...
<DisableOutOfProcTaskHost>true</DisableOutOfProcTaskHost>
</PropertyGroup>
Found here.

Clean and rebuild solution worked for me.

Adding this in each project is a cumbersome task. So you can set it in the environment variables.
Click Start>> Right-click Computer >> Properties >> Advanced system settings >> Click Environment Variables button to open the dialog, then under the System variables section, click New… button, type the Variable name = DISABLEOUTOFPROCTASKHOST, and type the Variable value = 1, then click Ok.
More here

I'm using VS 2013, VB.NET, and Windows 10, 64 bits, by the way
Just change in XML properites , Services : .NET Framework 4.6 instead .Net Framework 2.0 (Default)
and working fine for me.

I try adding the follow but didn't works
<PropertyGroup>
...
<DisableOutOfProcTaskHost>true</DisableOutOfProcTaskHost>
</PropertyGroup>
this solve this issue for me, adding the same as enviroment Variable
DisableOutOfProcTaskHost=true

I encountered this error when trying to build a sample solution that was included in some software that was installed under C:\Program Files\. Visual Studio prompted me to restart with elevated privileges (as it does when opening a solution in a "secure" location), however the build failed with the OP's error message.
Copying the solution to a "normal" folder (e.g. C:\Temp) solved it for me.

I tried opening an old VS2010 vb project inside VS2013 recently and just ran into this problem. I got around it this way:
I went to the vb project's properties page
I clicked the "Debug" tab
In the "Enable Debugers" section, I saw that the "(x) Enable the Visual Studio hosting process" checkbox was already checked.
I tried un-checking the "( ) Enable the Visual Studio hosting process" option
I saved these changes (Ctrl+S)
I then checked the "(x) Enable the Visual Studio hosting process" checkbox once more
I saved these changes (Ctrl+S)
My next re-build of the project was then successful.
Luckily, I was able to observe how the .vbproj file changed in my version control, and saw that it added the following line into it (which was not there before, despite the checkbox already being set initially):
<UseVSHostingProcess>true</UseVSHostingProcess>

None of the answers in this worked for me. I had to run Visual Studio as admin. Hope this helps someone in the future!
If you don't know how to run a program as admin on Windows, click this link.

Old DLL file keeps being used

I have a seemingly random problem where my project will run using an old version of a DLL file that no longer exists. Sometimes the real version of the DLL file will be used, other times an ancient version of the DLL file will be used. Who knows where Visual Studio is getting this DLL file from - it's months out of date!
I know that it is using the old DLL file, because when the application runs I start getting weird 'TypeLoadExceptions', complaining that methods don't exist or don't have implementations.
The following actions will sometimes help, sometimes not:
Restarting Visual Studio
Restarting the computer
Cleaning and rebuilding the solution
Deleting everything in \WINDOWS\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files
Searching for and deleting instances of the DLL file in \Documents and Settings\username\Local Settings\Temp
Sometimes I perform all of the above steps, and it still uses an old copy of the DLL file. Where is it hiding it?!
The same issue exists on our TeamCity server which is using MSBuild. When TeamCity tries to run unit tests it uses an old DLL file.
Now, I know that I can use assembly redirection in the web.config file, but the version number of the DLL file hasn't changed (I don't bother to update it, so it just stays at version 1). I don't want to have to start versioning the DLL files just to solve this problem. I would just like to know which particular caches I need to clear so that I can get on with developing.

It hides it in the GAC. There it may reside indefinitely. Using a more recent version may indeed solve the problem, but there is an outstanding bug in Visual Studio that has to do with choosing the correct version of DLL files. (If DLL Hell wasn't bad enough, the Visual Studio team is making it worse!)
Finding it in the GAC is tricky, and I cannot advise you on how to do that, but once the old version is deleted from there, it will not be found again. Sometimes, even though you are pointing the compiler at a newer version (by date), it will use the older version, because it has the same version level (by version). That is its bug.

Who knows where Visual Studio is getting this dll from - it's months
out of date!
The Modules Window is your friend...
It'll tell you exactly where that file is coming from. You can even use it with arbitrary processes if you attach the debugger.

I too would guess that they're hiding in the GAC.
You can look in 'C:\Windows\assembly' to see all the dlls and unregister yours from there.

The problem may exists with the build order or your projects.
If your Test project is built before the application project, this cause the behaviour you describe. To fix this: right click on your main project in VS and select the Project Dependencies... option and check the build order. Changes to the build subsequence can be made here by correctly setting these dependencies.

I had a similiar problem (but without Visual Studio). I am loading a .NET dll using UnsafeLoadFrom.
On one computer (a terminal server) the old file still remains being used, regardless of updated version numbers, etc.
The reason is simple: As long as a program instance is running, which has already loaded the old dll, the new dll will never be used. All further UnsafeLoadFrom will become the old dll although the old version doesn't exist on the harddisk anymore, because it has already loaded some time ago.
The solution is to shut down all running instances of the application or even restart the computer. Then all new instances will get the updated dll.

In my case, this was caused switching to Release mode, which had a different configuration (that used different location of the DLL).

In my case, I use Visual Studio to Publish Website, and though I check the reference of the dll file has changed, but the published dll still is old. Finally I new a Publish Web Profile and choose the right configuration (such as Debug - x86 / Release - Any CPU), publish again then the dll is corrected.

While this question is old, maybe someone will stumble upon it again in his/her quest for finding a solution.
In my case i got a CS0433 error for an ASP.Net page. After deleting the content in the obj\ and bin\ folders of the project, it worked again. Probably has to be done with a closed Visual Studio. Maybe also clean out those folders in referenced projects in the same solution (if used in the project and not pulled via Nuget).

In my case, the old DLL was in
C:\Windows\Microsoft.NET\assembly\GAC_MSIL\MyDLL\MyDLL.dll
It DID NOT show up in c:\Windows\assembly.
I did a search of my drive for MyDLL, and it showed up as indicated above. I was debugging my test app at the time, and tried to delete the offending folder...no go...it was locked by Visual Studio. I had to stop debugging my app, close Visual Studio, and then delete the folder. Problem solved!! I don't know how my DLL got there, but it hasn't showed up there since I deleted it.

It's possible that the DLL is being referenced from another folder. It could even be on a network drive if you have one in your PATH environment variable. Here's how Windows searches for DLLs:
http://msdn.microsoft.com/en-us/library/7d83bc18%28v=vs.80%29.aspx

In My Visual Studio 2015, I ensured that the offending Visual Studio project's Reference Path Listing is empty:

If you find such problem ,delete your Reference dll and pdb extensionfile add new references and rebuild your project .This often happens due to no rebuild of project,commit and updates.

The fix for me was making sure that the virtual directory in IIS was pointing to the correct directory. I have two projects on my system, a v4 and a v5. The virtual directory on my dev system was pointing to the v4 bin directory instead of my v5 bin directory - oops!

The file that was being cached in the dll, I couldn't trace the file, so I ended up renaming the file. This might not resolve the problem mentioned here but this was the fix that worked for me related to this question.

I tried a ton of things including re-installing VS 2107.
You can see where the DLL files are being loaded from in your Output window. After going through all mine looking for project DLL, I found it.
Clearing this worked for me.
C:\Users\YourUser\AppData\Local\assembly\dl3\222Q4G1T.8AT\JBEAR7PB.E3J\8bfcf9ab\6e61cbd5_30acd401\YourDLL.dll'
I actually deleted all the files in:
C:\Users\YourUser\AppData\Local\assembly\

Holy Crow! I had an old, old suite of applications including 2 web services and a bunch of class libraries and a click once application. Well, click once stopped publishing for VS 2005 with a bunch of 'not found' errors. So, rather than hack away at my registry as suggested on this site, I figured it was time to upgrade the projects to 2017. Well, when I did this, the projects references in my web service projects got lost. Then, rather than helpfully just telling me that with errors, VS 2017 must have went to some cached file in C:\Users\XXX\AppData\Local\Temp\WebSitePublish or C:\Users\XXX\AppData\Local\Microsoft\VisualStudio\8.0\ProjectAssemblies or C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files\root and 'helpfully' just used those files instead! I had to do a hardcore search with a custom program to find all the files on my C:\ drive and delete them before I finally got the errors!