I am using Microsoft Visual Studio Enterprise 2022 (64-bit) - Current Version 17.4.4
I have one .Net core project solution.
In one of the classes where I have declared an object for a class reference, when I try to "Go to Implementation" (Ctrl + F12) it leads to the decompiled class file which is not editable.
Expected: It should lead to the original class file.
I tried the same in other systems and it is working fine due to which it narrows down our issue to system specific for VS 2022.
I have also ensured that the proper using directive is provided to the class from where I am trying to access the "Go to implementation" for other class.
I also tried restarting my Visual studio 2022
Please provide any support to fix the issue.
Thank you in advance.
Related
I have Visual Studio Code (v. 1.69.2) running on OSX and it's not doing the following:
Doesn't highlight any classes (custom or system classes)
⌘ + F12 doesn't go to implementation of a class or method
Doesn't show tooltips over System classes indicating what library they come from, etc.
It does do the following:
Highlights basic system struts like int, double, string.
Gives intellisense autocomplete while typing.
Some background:
I have the C# (OmniSharp) extension installed and up to date. My VSCode is also up to date. My projects are all .net core 3.1, there are multiple projects in my folder along with a solution file. I've tried "⌘ + ⇧ + P" choosing "OmniSharp Select Project" and selecting the solution, but it doesn't resolve the issue.
The most annoying part is not being able to see the tooltips regarding what exactly a class is and what library it's coming from. For example I was "Using System.Security.Claims" and when I type "User" down in the code, it autocomplete it's available methods but I get no details on what the class is or where it comes from. Is this just the way things are with VSCode, if so it's bordline unusable.
Am I using the wrong extension? (seems to be the Microsoft suggested one)
Screenshots:
I ended up installing Visual Studio for Mac 2022 (not Visual Studio Code), for work with another project. This re-installed .net core 3.1 on my machine. After that my Visual Studio Code IntelliSense (OmniSharp Extension) started working. Now I can right click and go to definition etc.
So not sure what the initial issue was, but seems a re-install of .net core 3.1 worked. If anyone else runs into the issue, I'd suggest first removing the OmniSharp Extension, restarting your Mac, restarting VSCode and re-installing the extension. If that doesn't work uninstall VSCode entirely and re-install. Basically after a fresh install of .net core framework everything worked.
This page seems to indicate that the ability to move a type to another namespace is finally native to Visual Studio -- and should be available in VS 2017 (as the URL indicates).
But this is all I see in the refactor menu:
How do I enable this behavior?
In short: I need to open an application originally built in Visual Studio 2008 (version 9) in Visual Studio 2013 without upgrading the project since the overall project architecture must remain the same for when I check it back into source control.
Details: I need to open a Visual Studio solution (.sln) inside Visual Studio 2013. The solution in question was originally developed in Visual Studio 2008, so when I try to open said solution in Visual Studio 2013, I am shown a prompt with the projects within the solution checkmarked, with the message:
These projects are either or supported or need project behavior impacting modifications to open in this version of Visual Studio. Projects no displayed either require no changes or will automatically be modified such that behavior is not impacted. Visual Studio will automatically make functional changes to the following projects in order to open them. You will not be able to open these projects in the version of Visual Studio in which they were originally created.*
My attempt at a fix was to just upgrade the solution and hope for the best. This is successful, but after building and attempting to run the main project, I see the following build error:
The type 'Microsoft.Web.Services3.WebServicesClientProtocol' is defined in an assembly that is not referenced. You must add a reference to assembly 'Microsoft.Web.Services3, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'. *
I then tried both commenting out the references to this assembly and adding in the missing reference. Okay, so then I rebuilt the solution and attempted to run. Same error, but for a different assembly. Repeat fix, same error for different assembly. This pattern continues and continues, and at this point I realize this is unacceptable anyway, because when I make a change to this solution, I need to check it back into source control. When others open it, they may be opening it in VS2008, and therefore this “upgraded” version is inconsistent with the version the business uses. I need to open the solution originally build in VS2008 in VS 2013 (can't work around this, needs to be VS2013). If it helps, I'm using 64 bit Visual Studio 2013 Ultimate.
Any help or guidance will be greatly appreciated!
As several of the commenters have already helpfully pointed out, this is not possible. Round-tripping (i.e., opening and manipulating project files created by an older version of Visual Studio in a newer version of Visual Studio) was not supported until Visual Studio 11. The only way to open a Visual Studio 2008 project/solution in a later version of Visual Studio will be to convert it.
As far as interoperability with previous versions is concerned, you have two options:
Update the project locally (using the migration wizard provided), make any changes to the project file necessary to get it to build, and then edit the code files. Once you're satisfied with your edits, commit only the modified source files, not the project infrastructure files. Your fellow developers, stuck on VS 2008, won't notice any difference.
Update the project locally (using the migration wizard provided), make any changes to the project file necessary to get it to build, and then rename the project file (e.g., by appending a -vs2013 suffix to it). Commit this to your code repository. You will now have two project files in your root directory, one for each version of Visual Studio that your team works with. From here on, you just open the project file corresponding to the version of VS that you have installed.
I used approach #1 for a good part of last year, where I spent most of my time developing a C++ application in VS 2010 on a desktop machine, but also wanted to work on it on my notebook running VS 2013. Of course, in my case, it took a trivial amount of time for the automatic conversion to upgrade my project file after pulling from source control. I didn't have to do any tweaking thereafter to get the project to build. It sounds like your case is different, so option #2 might be a better choice.
I want to find the type of a project in visual studio. I found some information when I did research which didn't give any information on how to find the sub type of a WCF project when projecttypeGuid of the .csproj file is compared with the list present on MSDN website and in the below links. When I compare, i'm getting C# and Web application as project types but i have two projecttypeguid's that are separated with semicolon in my .csproj file, which didn't give a way to check what type of WCF project it is.
Some of the the links which I referred are :
How to find out what type of project I have in Visual Studio 2010
How do you tell the Visual Studio project type from an existing Visual Studio project
determine project type in visual studio
I think you'll find this question useful. It identifies registry keys that are supposed to enumerate the project "Types" and "Flavors", which are the first and second guids, respectively.
What is the significance of ProjectTypeGuids tag in the visual studio project file
It may be the case that you'll have to inspect a different registry key, depending on the version of Visual Studio you are using. This example uses Visual Studio version 10 (i.e., VS 2010). When I inspected a "similar" registry path for Visual Studio 12, HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\12.0, I found no Packages subkey, so the method may have changed.
If you will provide greater detail, such as the version of Visual Studio and ASP.NET, or the specific project GUID, I think we can drum up a more useful response.
Cheers!
I think if you go to the properties window of your project you will see the information following this image below.
Please look at the output type. It shows Class library. If your project shows windows application then the output is a Windows Application.
I have a project that was originally developed using Visual Studio 2010 with .Net 4.0. It is a class library that implements a custom MVC 3 controller and it uses a dynamic type. If I open the project in Visual Studio 2012 RTM, without making any changes to the project, I get the following error on the dynamic types:
One or more types required to compile a dynamic expression cannot be found. Are you missing a reference?
I am also getting another error, which is:
Missing compiler required member 'Microsoft.CSharp.RuntimeBinder.Binder.InvokeMember'
They seem to be related issues. I am not sure why Visual Studio 2012 is confused. The Microsoft.CSharp assembly is in the references. If I open the project again in Visual Studio 2010 it compiles just fine. Has anyone come across this issue and know a solution to it?
In my case reference to Microsoft.CSharp assembly was missing. I got this error when trying to use JSON.NET, dynamic types and Visual Studio 2012.
The answer turned out to be in a warning that was present when compiling in either VS 2010 and 2012. The warning was:
The predefined type 'System.Runtime.CompilerServices.CallSite' is defined in multiple assemblies in the global alias; using definition from '..\IronJS.Core.0.2.0.1\lib\net40\Microsoft.Scripting.Core.dll'
The project used IronJS and it had a a copy of Microsoft.Scripting and Microsoft.Dynamic in its package that were being referenced. I removed these references and referenced the versions in the global assemblies and everything works fine. Not sure why VS 2012 had a problem with this when VS 2010 did not. Or why it caused the obscure errors.