Every where I look Quick Info in Visual C# looks something like this:
Yet my Quick Info box only shows the name/declaration, without any description.
Are longer descriptions cut from the C# Express version? Or am I doing something wrong? XML comments I'm making work as intended, if it helps.
It depends on the specific framework target and type you selected. But for a 4.5 desktop app, this information comes from an .xml file, C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.5\mscorlib.xml. The relevant part of that file is:
<member name="T:System.DateTime">
<summary>Represents an instant in time, typically expressed as a date and time of day. </summary>
<filterpriority>1</filterpriority>
</member>
So check if that file is there.
Thank you alex and thank you Hans. Both of your answers lead me to my solution. Also thank you for as quickly answering as you did.
The Road to Solution (might be useful for some, if not skip to The Solution).
The file Hans mentioned did exist. Also it did for version 4.0. I also tried to install documentation for Visual Express (as per alex's tip) only to find out that Visual Express 2012 installer doesn't have any options during installation (at least not that kind).
C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework also contained v3.5 folder, but there was only a Profile folder and no mscorlib.xml (or other files that v4.5 and v4.0 had).
Realization came when I found out that Unity3d uses Mono equivalent of .Net 3.5 and in the project setting I found that it was setup for .Net 3.5 (if any one is wondering - Visual Studio is used only for coding, Unity compiles everything).
Few hours of searching later I did find the "documentation" for .Net 3.5.
The Solution
What is needed is Microsoft Windows SDK for Windows 7 and .NET Framework 3.5 SP1. The only thing required to check during installation is Developer Tool->Windows Development Tools->.NET Development Tools. All the Quick Infos for C# functions in my project are now showing correctly!
A note: I tried to find mscorlib.xml for .Net 3.5 afterward but no luck, so I don't know where or in what format the XML documentation for .Net 3.5 is kept but I'm happy as long as it works.
More likely, the documentation is cut from the express version to reduce the download size. Have you installed documentation with the visual C#?
Related
my client using visualstudio 2010 for his application and app OS version is windows 7. they shared the sourcecode of that application and asked me to migrate that code into VSTS. but, i am using visualstudio 2019 with OS version windows 2010 in my system. can we use that sourcecode in my system. any compatabilities are there ?
Yes, but you will most likely have to adjust for the target runtimes/frameworks and configuration differences that the VSProject file will have between the versions. The VSProject file will almost certainly migrated to the latest version for VS2019.
You may not be able to if the target runtime/framework for the application is not supported by VS2019. For example, if it something less than .NET 4.5.2, you may run into problems.
The best solution is for you to get his system, his version of VS and the code base updated to the latest. If this will be a significant effort on your part, tell your client that migration will be a billable item.
If you're merely trying to share code, write, but not build anything you can certainly use VS2019, but at that rate, you may as well us VS Code.
There is no such thing as visual studio 2010 source code. THere is source code, that has been written in VIsual Studio, but a .cs file is a .cs file, regardless of the editor. A text file is a text file. Source code is not like word, where there are a ton of formatting information embedded in a file format that is complex - source code are SIMPLE text files.
2010 to 2019 MAY be a little large for the project file - you have to try it out. That being said, making new project files is trivial.
2010 likely (not sure, it is like ages ago) does not use nuget - you likely run into more problems with .NET versions and links to third party libraries.
I need to use .NET framework 3.5 for my project because it uses some older functionality.
The tooltips in Visual Studio aren't showing descriptions like they do when targeting a later framework. I just see basic information like method signatures and data types. Is there a way to fix this?
I looked for the xml files in C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v3.5 and it looks like it just has the files for the 3.5 Client Profile.
I tried reinstalling the 3.5 framework from this link: https://www.microsoft.com/en-us/download/details.aspx?id=21
I have no idea if it's working or not. When I run the executable nothing happens. I tried running as administrator. When I run it from command prompt there is no output.
I noticed the file is a hundred times smaller that the download for the latest .NET framework. Does that mean it doesn't include the files it's supposed to?
I'm guessing if there's a fix, it's either getting the correct xml files for .NET 3.5 or getting Visual Studio to use the xml files for .NET 4.6 even though my project is targeting 3.5.
Thanks in advance!
I don't think the earlier versions of .net provide the level of tooltips that your after unfortunately. One last thing you could try is to ensure you have all of the elements in the "Add windows programs and features" enabled. Not sure what version of windows your running on but this should explain what I mean:
https://learn.microsoft.com/en-us/dotnet/framework/install/dotnet-35-windows-10
You can enable the .NET Framework 3.5 through the Windows Control Panel. This option requires an Internet connection.
Press the Windows key Windows Windows logo on your keyboard, type "Windows Features", and press Enter. The Turn Windows features on or off dialog box appears.
Select the .NET Framework 3.5 (includes .NET 2.0 and 3.0)
check box, select OK, and reboot your computer if prompted.
You could try downloading the whole installer not just the bootloader installer.
.net 3.5 sp1
http://download.microsoft.com/download/2/0/e/20e90413-712f-438c-988e-fdaa79a8ac3d/dotnetfx35.exe
or if you dont want sp1
.net 3.5
http://download.microsoft.com/download/6/0/f/60fc5854-3cb8-4892-b6db-bd4f42510f28/dotnetfx35.exe
Edit
If you are unable to run the installer at all it sounds to me like it is already installed. You could try to verify the installation using this tool. This page also explains how to find the setup logs. It should shed some light on what is happening.
The mentioned version of the TeeChart was released at the End of January 2013. The included TeeChart.dll has version (e.g. the .net40 one): 4.1.2012.1312. Unfortunately this version is smaller than all previous version of the TeeChart released in 2012. Actually the version should be 4.1.2013.1312, but it is not. Because of the version mismatch the WindowsInstaller is not able to upgrade this library. It uninstalls the previous one, but doesn't install this one, because its version is older as e.g. 4.1.2012.2283.
So does anybody (specially Steema guys are asked here) has any idea how I'm supposed to distribute that by a normal Visual Studio vdproj setup???
What I'm currently doing is: I modify the 'File' table within the MSI file and set the value of the 'Version' column for the TeeChart to the correct version and it works. Unfortunately this version is the last one, which my license includes, so I'm not able to skip it and move to any of the following versions of 2013 without buying a new license.
First of all, bear in mind that *.vdproj projects are a deprecated Microsoft technology as you can read here:
The Visual Studio setup projects will not ship again – VS 2010 was the
last release with support for it. So, you’ll want to make plans to
migrate to something else.
Having that in mind I can think of the following options:
That's an unfortunate coincidence. However, if you stick with *.vdproj, you might need to upgrade your TeeChart subscription to get an up to date assembly.
Alternatively, you can use a workaround similar to what 0xA3’s answer here.
Considering that *.vdproj is an obsolete technology and given OxA3's answer, you could upgrade your installer builder toll as suggested in Christopher Painter's comment:
I've been down that road with VDPROJ and in no time you'll hav dozens
of these postbuild scripts to get around the fact that VDPROJ sucks.
Dump VDPROJ now for another tool (WiX or IS 2010 LE ) and you'll have
a longer life. :-)
So on my computer I only have Visual Studio 2010 Express. I need to edit a Visual Studio 2008 project, however it needs to be kept in C# 3.5.
Before I open it in 2010 and accidentally upgrade it, will it be kept in 2008 or C#3.5 format?
I realize I wont be able to use .Net 2010 features, so thats no problem. I just want to make sure if I save my 2008 project using 2010 I will still be able to open it in 2008 and it will work fine.
The target framework of the project is independent of the solution format. That is, you can convert your project to Visual Studio 2010 and still target the 3.5 Framework. But, once it's converted to 2010, you will not be able to open it in 2008.
You cannot open a project in VS2010 without it being upgraded. The Framework version can be controlled independently, so you can still target 3.5.
The changes to the project/solution files to use 2010 (assuming you don't use any newer features) are fairly minimal, so there may be mileage in just not committing the project/solution files (you can probably achieve this by dropping an ignore file for your source control provider in your local folder, including adding the ignore file to itself, so that doesn't get committed).
If you're mostly editing code (and not often changing the projects in the solution, or files in the projects) you could also have two copies of the files, one for each version, until you can commit to 2010 everywhere (and with Express for free, you might be able to do this quickly?).
No, VS2010 will convert the VS2008 project file. After it is converted, VS2008 can no longer open it. There are ways to hack around this, the simple solution is to just use VS2010 consistently. Next best thing is to only check-in the source code changes. Next best thing is to give the 2010 project a different name and maintain them both, at least for now.
You'd be hard pressed to accidentally upgrade it. When you open a VS2008 project in VS2010, it automatically starts the upgrade wizard, and you have to decide whether to let it do the upgrade, including making a decision whether to let it take a backup before it does the upgrade.
You can't open a VS2008 project in VS2010 and work on it without upgrading it to VS2010 format first. And once you've allowed VS2010 to upgrade it, you won't be able to open it in VS2008 any more.
Careful though - don't confuse the version of the framework you want to target, with the version of VS that you're using.
You can target framework 3.5 with VS2010.
There are hacks that let you open VS2010-upgraded projects in VS2008, but it's not a great plan to go down that road (guess how I know).
When you are going to convert it with compatible to 2010 it will ask for the backup...
so... later you can retrieve your file back ...
I might be wrong but I'm almost sure that project files don't differ between 2008 and 2010 or at least they are compatible. Solution files are a different matter and old solutions do indeed need to be converted. Usually you have few solutions for 2008 and 2010 versions of VS, but they contain the same projects, so the projects don't need to be converted.
I was on a seminar where they took this (short of classic?) accident as a sample for versioning. They get a 2008 project from git and start it in vs 2010.
Did the upgrade process and then "ops, i can't revert the upgrade". They commited the vs2010 converted files to a branch in GIT. When they "came home again", merged the changes in project together with 2008 solution files.
This may not come in touch to you, but the sense is:
All files is intact but the solution/project files. So just keep them safe and you can continue use the 2008 version after done your editing in 2010.
Though, without any kind of manual handling of solution/project files - answer (on the question in your subject) is No!
In short, no. Once it's upgraded, it stays that way. There is no official way to downgrade it either. The main driver behind this fact is because of the compiler. Even if you stay in .NET Framework 3.5, you can still use C# 4.0 features (like optional / named parameters) since 2010 will always use the 4.0 compiler.
Imagine a situation where it stayed in a 2008 format but you used a C# 4.0 language feature. Since VS 2008 always uses the C# 3.0 compiler, whenever you open it in 2008, it will no longer compile. This is a good reason to avoid work-arounds that have been posted for downgrading - you get mixed compiler features that can break things pretty easily.
We have a team on vs 2005. We want to upgrade to vs 2008 but want to do it incrementally. If we have a few folks on the team upgrade to 2008 (still targetting the 2.0 framework) while others working on the same solutions stay on vs 2005, would this cause any issues .
Do solution or project files change due to this?
Are there any backward compatibility issues to deal with or other conflicts that is going to force a big bang upgrade for the team?
Why do you want to upgrade incrementatlly? You can still target .NET 2.0 while working with Visual Studio 2008.
Won't work. 2k8 upgrades your solutions.
Let me qualify that. Solutions, once upgraded, can't be opened in 2005. I believe individual projects can be.
So, one solution might be to make a copy of the solution, call it project.2005.sln, then upgrade the original solution and call it project.2008.sln.
I don't have 2k5 on my box, so I can't test this. It would be simple and, as long as you check in fully beforehand, non-destructive to test this.
You could achieve this by renaming all of the solution/project files (leaving the actual source alone) - then members of your team can load the version appropriate to them.
For C#, the project files are almost identical (different version number, new target platform property). VS2008 however will always try to "convert" the old VS2005 files, while VS2005 refuses to open the new files. Therefore, a mixed environment is not very practical.
What we do with mixed VS versions is create the solution in 2005, with all the project's set up. Then check that into SourceSafe (or whatever you use). Then the users with VS2008 upgrades the solution locally on his machine, then undoes the check-out VS2008 does when it upgrades the solution and everyone can then work on that project at the same time, as long as no changes are made to the solution file!
As far as I know it is the solution file (*.sln) that is changed when upgrading to VS 2008, not the project files .csproj/.vbproj.
So you can use both IDE's for the same gode if you have different .sln files.
We've been doing exactly what you want to do for about 6 months now.
Our experience has been limited to Web Application, Class Library and basic WinForms projects. But we've had no issues with developers split between 2005 and 2008.
You will need two seperate solution files (one for 2005 and one for 2008) but they differ only in that one contains the string "9.0" and the other "10.0".
The project files will be modified by 2008, however it basically only adds new attributes which are ignored by 2005.
2008 Project files ARE compatible with 2005, in my experience.
2008 Solution files are not, but creating a compatible copy is a simple task of replacing the "9.0" with "10.0" or vice versa.
If you are dealing with Web Application projects, there is one additional change you should make to the project file so it is compatible with both version.
See my answers here and here for details.
go for the big bang, 2008 rocks compared to 2005. I have no problems found whatsoever with converting projects.
Partly possible but must be carefull.
Need a version control system (and build server with 2005/2008 based config)
Separate solution and project files based on VS.NET version. Everybody should open just corresponding .sln van .proj files. (Some hints about project file changes: .NET 2.0 Project in VS.NET 2005 != .NET 2.0 Project in VS.NET 2008)
It's possible to commit common C#/VB.NET source files, XML files. Other files - lets say .resx - can causes pain.
I think it's more easier to switch all projects to VS.NET 2008.
One note to VS.NET 2088: we have strange experiences with WinForms designer and had some after-build freezing.