I have all my references setup to "PackageReference" and it works and builds fine but I don't have intellisense with Razor. I can't move to .netcore, but it builds and runs fine I just lose a lot with intellisense. I guess I can do the "choose" switch in the csproj to point it to DLLs, but what is the bare minimum that I need to get intellisense to run?
All my references setup to "PackageReference"
How do you handle the references like system, system.web?
We should only need to change the format of Hintpath in xx.csproj(assemblies from nuget), and keep other things the same. If this is actually what you did, close vs=>delete the hidden .vs folder in Solution folder=>restart vs and reload the project to check if Intellisense can work now.
In addition: It's not officially supported to migrate asp.net full framework projects from packages.config to PackageReference format. For me, I use this extension in VS2017 to make this job for me, you can give it a try. And there's one discussion about the official support for that migration in DC, you can vote for it and track the latest info there.
Related
Looked through some similar questions, could not find one that fits my case.
I have a solution that I created some time ago in VS 2010 (maybe originally in MVC2), and eventually upgraded to MVC4.
The solution works properly when opened with VS 2010, builds and runs - everything as expected.
To confirm that I use MVC4, I checked the properties of my System.Web.Mvc.dll. It appears to be 4.0.0.0
From this I assume that I have MVC4 successfully installed on the machine.
However, when I try to open the solution with VS 2012 I get the following infamous error
Full text:
Unsupported This version of Visual Studio does not have the following
project types installed or does not support them. You can still open
these projects in the version of Visual Studio in which they were
originally created.
- Recipes, "C:\ ... Copy\Recipes\Recipes.csproj"
I can also create a new MVC4 project using VS 2012, so I'm assuming I don't lack any tools VS 2012 needs.
What else could be the problem?
There's probably an entry in the <ProjectTypeGuids> element of the .csproj file that VS2012 doesn't recognize. I have a vague recollection there was some tooling identifier change but I can't recall specifically.
My suggestion would be to create a new project from scratch and then compare the <ProjectTypeGuids> elements in each .csproj file to try to figure out which one from the VS2010 project it doesn't like in VS2012. It's likely going to require some trial-and-error tweaking of the list so make a backup of the file first so you don't get yourself into a situation where you can't open it at all.
If you don't want to take that approach another option would be to create a new empty project and then import the individual files from the old project into the new, but that could obviously be quite time-consuming if it's a large project.
I wanted to update some DLLs used in my .NET project to the latest version and I've noticed that, if I replace the DLLs on the file system with their new versions, VS 2012 updates the DLL version number in the Properties window.
Is this some new feature of VS 2012? I don't remember seeing it in VS 2010 (I expected it would need more manual handling).
Is this working right, or should I remove and re-add the DLLs manually from the references, just to be sure?
Anyway, my project compiles and runs fine, so I guess it works...
EDIT:
I guess it works because the DLLs are not strongly named (http://msdn.microsoft.com/en-us/library/wd40t7ad.aspx)?
Perhaps I should re-add them if they were...
Inside the project file I saw it had the old version number, but in the properties window I saw the new one...
Thanks!
Easier option to refresh / reload references & types DLL (for example COM interop types) without re-adding all DLLs one-by-one is to reload all projects that reference it like this:
It's better to remove and re-add your references. You said it yourself that the project file was not up-to-date.
I am not sure if there is an add-on for VS that could make updating DLLs easier. If there isn't one, definitely someone should make one. Changing assembly references in large projects is a pain in the #ss.
What worked for me is - go to 'manage nuget packages' and update all.
Managing references as NuGet packages is significantly easier. You can view which references became out of date and choose which to update.
Downside: if you are not using the standard packages (available via NuGet.org) you have to manage your own NuGet repository.
You can manage your NuGet packages via GUI or console.
NuGet packages manager GUI
better option is to de refrence the dll and refrence again but make sure for safety purpse you keep the backup of your previous dll...
So I am working on a solution with a lot of projects with multiple developers using SVN. There are some projects that are specific for me that I want loaded but for others they might not be relevant.
So my question is, where does Visual Studio store information about a project begin loaded and what is the proper way to commit project/solution settings with out ruining it for others?
An example could be that I just added a new project to the solution and I want to commit these changes, but I don't want to commit whether or not a project is loaded/reloaded (Since other developers have to reload them again).
EDIT: I found the answer here When I unload projects in visual studio, where does VS save this setting?
When you add projects to a solution, they will get loaded when the solution opens.
If using source control, if such a solution is updated and contains new projects, they will get loaded.
One way of dealing with this is to create multiple solutions - solutions that only have relevant projects. These solutions can be part of source control, but don't have to, though if you don't add them to source control you risk having projects in source control that only you have a solution reference to.
Sometimes I've seen a solution that includes up to three .csproj files for each project in the solution. Something like this:
Project.UI.2005.csproj
Project.UI.2008.csproj
Project.UI.2010.csproj
and the same with .sln files:
ProjectSolution.2005.sln
ProjectSolution.2008.sln
ProjectSolution.2010.sln
So if you copy the solution and want to open it using VS2005, you just need to open Project.UI.2005.csproj or ProjectSolution.2005.sln.
What is the best way of creating those 3 (or 2) files, in order to be able to open the same solution in multiple versions of Visual Studio?
Maybe the only way of doing this is modifying manually the .sln/.csproj. If so:
How can I modify those files correctly so I won't crash the solution?
I want to do this because sometimes I develop applications using VS2010 and when deploying the source code to my customers, they can't open it in VS2008, and then I have to do some tweaks.
Note:
I know there will be referencing and compiling problems if I use features only included in .NET Framework v4.0, or similar. Let's suppose all the projects in the solution are compiling under .NET Framework 2.0 (specified in the project properties).
I finally ended developing a small application do to this.
I'm still testing it, but it is working good so far.
All you need to do is, select the .sln file you want to convert, and specify the versions involved in the conversion, and it will do all the work for you.
If you have a VS 2010 project:
Solution (Solution.sln)
Project_1 (Project_1.csproj)
Project_2 (Project_2.csproj)
and you want downgrade the version (to 2008), it will keep those files, and also create:
Solution.2008.sln
Project_1.2008.csproj
Project_2.2008.csproj
And you will be able to open Solution.2008.sln with Visual Studio 2008 without problems.
As soon as I finish it, I'll share executables and sources here.
I have a project on SourceSafe that the team work with VS 2005.
I have installed VS2010 and like some features of this version.
Is there a way that I keep the project to day with SourceSafe, but however work locally with VS2010.
Say, I could not add new files to solution, but at least obtain, modify and archive the existing ones.
You can update all of the source files pretty safely unless you're adding code that is new since VS 2005. The main difference between the VS versions is in the project, and the solution files. What you can do is make your local project and solution files writable, and then use your source control to modify the source files. When all is said and done though you'll want to build it in 2005 (with the SourceSafe versions of the project and solution files) to make sure it all still works.
Also note that the conversion utility in Visual Studio that converts projects from previous VS versions is only intended to convert projects from the previous version. Since VS 2010's previous version is VS 2008 and not VS 2005 you may have to perform manual changes on your solution and project settings to get everything to build. The main thing that comes to mind is how global include directories are handled. If you have access to VS 2008 convert it to that first, and then to VS 2010.
Besides targetting the 2.0 framework VS2010 will still let you use new language features so you have to be careful.
And as Ben Burnett said, the sourcesafe binding doens't have to be a problem as long as you don't check out project and solution files. You can remove the read only flag from them so VS2010 can edit them, but they don't need be be checked into sourcesafe.
But I really wonder which feature you like so much about VS2010 that you want to restrict yourself to not be able to add, remove or rename files from your project.