It seems I managed to completely break my Visual Studio 2015 setup by uninstalling Nuget Package Manager. I uninstalled it in order to fix its inability to update anything. Now, when I try to launch VS I get a plethora of error messages, but the most important one seems to be shown on the image below as its showing no matter what fix I attempt:
Here are the steps I took before I started seeing the above error:
I have renamed the Extensions folder found at the following path:
C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE and installed Nuget Package Manager for Visual Studio 2015 from the microsoft website.
New extensions folder was created and when I tried to run the application with nothing else in it I would get the error message above once on VS launch and once on project load. When I moved old package folders from the old extensions folder I would get a lot more error messages related to the packages.
I also noticed there is an Extensions folder found at %localappdata%\Microsoft\VisualStudio\14.0, but renaming the folder to something else and just having blank folder did not help either. Also, I saw somewhere else a possible fix to an issue I thought was similar by removing contents of the folder located at: %localappdata%\Microsoft\VisualStudio\14.0\ComponentModelCache, but that didn't help either. Now with all this trying I am getting to a point where fresh install might be an only option.
UPDATE:
I guess I managed to overcome this issue by opening up this project in Visual Studio 2017. It worked without any issues, though when I originally cloned the repository from GitHub via Visual Studio 2017 it didn't work. Having said all that, I don't think its an answer I was looking for, but at least I can continue working on this project.
I am currently trying to integrate typescript into vs 2010 by following these instructions for windows 7 described here.
Please do not mark this as duplicate because I am having a problem with the provided solution to my question and cannot comment on the solution.
I followed your instructions closely but sadly it's not working for me. During installation of typescript I get an warning from VisualStudio concerning devenv.exe: Invalid Command Line. Unknown Switch : updateConfiguration.
After clicking okay the installer reports that the installation was successful. when I start VS without creating or opening a project, after a while I am greeted with another error:
Confirming, that I do not want to get bugged about this again i create a new typescript(!) project, which gets denied with a more severe notification:
I checked all the folder paths I added as parameters to the .msi file and it looks like everything is in place. Any ideas how to resolve this?
Thanks!
I suppose there is a missing folder redirection in the answer you referenced, the VSTools msbuild folder is not being redirected.
If you open up the %programfiles%\msbuild\Microsoft\VisualStudio\v11.0\Typescript folder, is the target file present there? Try copying the whole folder to %programfiles%\msbuild\Microsoft\VisualStudio\v10.0\Typescript.
On a more serious note, Typescript is usually used for Web Development, Web development project types are almost 100% backwards compatible between VS2012, VS2013 and VS2010, so why not upgrade to make use of these features.
It can hardly be a support issue, since backhacking Typescript into VS2010 is surely putting you in the unsupported bucket.
I am new to web development, and have been having a considerable amount of trouble trying to get my asp.net project running using Visual Studio 2010. Please help.
I am working on a web development project that references a database using SQL 2008 R2. I was having problems with turning on/off features on my computer, the asp.net and .net features, etc. I would get an error that read "An error has occurred. Not all of the features were successfully changed." I tried several solutions to fix this, and none worked. I ended up using a cleanup tool I found online, it said use as a last resort, which is where I was at.
Here is the link:
http://cid-27e6a35d1a492af7.skydrive.live.com/self.aspx/Blog_Tools/dotnetfx_cleanup_tool.zip
This ended up fixing my problems with the features, but then I was not able to use Visual Studio 2010. I got an error "Cannot create the window". To fix this I ended up reinstalling Visual Studio 2010. Now I am again running into the problem where I cannot turn on the asp.net and .net features with the same error as before.
Now that is not my only problem, I cannot open my project solution file. It is giving me 2 errors when i open the .sln file "The selected file is a solution file, but was created by a newer version of the application and cannot be opened." and "The system cannot find the file specified." in that order. The .sln file says it is an unrecognized version.
I have previously worked on this project using Visual Studio 2010, before I tried to fix the problems with the features. I can still open other .sln files that I worked on before, but they do not reference outside sources. I have tried opening the .sln file in notepad and changing the version from 12.00 to 11.00 (on line 1) and changing #Visual Studio 2012 to #Visual Studio 2010 (on line 2). I need to work on this project as soon as possible. Any help would be great.
Will someone help me identify the problem?
How can this problem be fixed?
You don't necessarily have to use an existing solution. A solution file just references a bunch of projects and groups them together.
I would suggest you create a new blank solution and then add all of your existing projects into that one, assuming you don't have a similar issue with adding in the projects as well.
A lot of people new to CI (Continuous Integration) install VS (Visual Studio) on their CI server "because it is required to compile the code". MSTest is a common reference brought up here.
Why should I not install VS (or generally speaking, any software not out-of-the-box) on my CI server?
(This question has not been asked before apparently, so I'm adding it for reference. If it already exists, sorry, I missed it, please merge. If no answer is provided to this question within some time I can add one myself)
Because you don't need to. A Visual Studio license is pretty expensive, so having one just lying around on a server where no one's using it is just a waste.There are a couple of arguments why you would still need to install a full blown Visual Studio instance on your Continuous Integration server - but here are their counter arguments:
Reason 1: I need it to compile.
Reality: No, you don't. You need MSBuild to compile, but that is available for free, in the Windows SDK. Note that there are several versions for different operative systems and .NET versions, so be careful to download the correct one.
Reason 2: I need it to make quick fixes on the server.
Reality: No, you don't. You shouldn't make quick fixes on the server - you should check out from your version control system, make the fix, build and run tests locally until it works, check in, and have the CI system do the rest for you. That's why you have a CI system.
Reason 3: Without Visual Studio, I can't run MSTest no my CI server.
Reality: Wrong. AFAIK, the MSTest runner is also part of the SDK (at least that's what it seems like on our CI server here - although I can't verify it since we don't have any tests at the moment...). However, a quick googling found this blog post which explains how to do it without the SDK as well. I haven't read through it in detail, so I can't promise that it works, or that it's legal. You have been warned.
Feel free to add more reasons in comments, and I'll counter them.
You might need to install Visual Studio anyway, out of practicality
I was going to try and refute the accepted answer, posted by #TomasLycken, in the comments, but found I needed more space to talk. Even though I technically agree with what #TomasLycken has asserted, here, I'll list some of the dependencies that I found difficult to install on my CI server - and leave it to you to decide how right the accepted answer is...
1 - 'mshtml' primary interop assembly
You can see the problem I was getting in my build output at this S.O. question I created and answered. Mind you, I spent several hours figuring out how get the desired PIA registered - and it was a result of running some .exe's on the server that came from my V.Studio installation - hmmmmmm
CONTEXT: I had a win forms project that used the Web Browser control.. and in the 'WebDocumentCompleted' event, I was casting the DomDocument to hshtml.IHTMLDocument2 .. and that's why I had a reference to Microsoft.mshtml in my project.
RESULT: Now #TomasLycken suggests I deal with this by fixing my code. At first, I wanted to bawk at this suggestion. My code is deployed and working! But, when I do a web search, I see that Microsoft doesn't really recommend using their mshtml PIA outside of the Visual Studio environment they developed it for.
The offending 10 lines of code was effectively doing a little screen-scraping of data on behalf of our users who do research on technical topics in several well-known web portals. But, when I tested this code, written in 2009, it appears that the DOM it once manipulated has now changed in 2016. I know shocking. Probably not my smartest bit of code. Probably time to retire this function - in other words, fix the code and recommit it.
#TomasLyken I think is right on this one.
2 - Win Forms Project post-build script
CONTEXT: So I had come across this cool post-build technique on S.O. that allows my app.config file in my WinForms project to undergo an XDT transform similar to the way my web projects' web.config files are transformed. Well, it just works OOTB, so-to-speak, if you copy from S.O. and into the .csproj or .vbproj source file. But, once you put all this onto a build server with no Visual Studio, the critical piece fails due to a dependency on:
$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.targets
Now this is straightfoward enough to rectify.. I just copied over to the CI server my C:\Program Files (x86)\MSBuild\Microsoft directory. But, should I? Since I've kinda went off the reservation of what Visual Studio normally would support.. one could argue that #TomasLycken's accepted answer is still right on this point, too.
3 - Just getting all the .NET Frameworks and Multi-Targeting Packs in place
Points 1 and 2 above, were actually the last things I conquered in my attempt to get my first build job to run. And my first build job is for a solution stack that I've created and maintained over the past 8 years.. so it has weathered a few frameworks and would have some non-trivial texture to it. I knew it wouldn't be easy. In fact, I hoped by making a CI server that could build this .sln, that it would in fact be ready to build most any other solution we threw at it.
When I first received my clean "Windows 2012 R2" server, it simply had a lot of things missing.. and I'm wondering if I had installed Visual Studio first, if it would have rectified some of these things straight off?
Below is my synopsis of what I had to do - but it doesn't show the pain and suffering involved figuring it all out and the false starts. Maybe it'll help someone else, though.
> First, uninstalled 4.6.1 framework
-- (find Update for Microsoft Windows (KB3102467) and click Uninstall.)
-- also uninstalled anything from MS labeled with C++ redistributable (a later step will restore these)
> Then, install Windows 7 SDK (installs critical "reference assemblies" and a proper baseline 4.0 framework)
-- Then, install Multi-Targeting Pack for Framework 4.0.1 (netfx_401mtpack.exe)
-- Then, install Multi-Targeting Pack for Framework 4.0.3 (netfx_403mtpack.exe)
> Then, reinstalled 4.6.1 framework for 2012 R2 (KB3102467)
> Then, installed Microsoft .NET Framework 4.6.1 Developer Pack (DP461-DevPack-KB3105179-ENU.exe)
> Then, installed "Visual Studio 2015 Build Tools" (BuildTools_Full.exe)
> Downloaded a copy of nuget.exe and put it in the C:\Windows directory
4 - Getting rid of 'missing ruleset' warning MSB3884
From #kevinbosman's post on this GitHub issues thread
If you don't want to edit your Microsoft.CodeAnalysis.Targets file, please note that it is not enough to merely copy the folder C:\Program Files (x86)\Microsoft Visual Studio 14.0\Team Tools\Static Analysis Tools\Rule Sets\ to the build server.
You also need to create the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\VisualStudio\14.0\Setup\EDev and add the string value StanDir = C:\Program Files (x86)\Microsoft Visual Studio 14.0\Team Tools\Static Analysis Tools\
5 - Getting MSTest to run correctly
Need dlls copied into your build machine, some must register w/GAC more info here specifically:
Microsoft.VisualStudio.QualityTools.Resource.dll
Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll
Need a hive out of your dev machine's registry copied into build server
some warnings, if you want them to go away, according to this Microsoft visual studio help forum require a VS 2010 and feature pack 2 installation.
My experience with TFS is limited. We run Team Foundation Server off a build server I will denote as 'Alice.' Alice has been working great until we ugraded to VS 2010; and with the urgency of a build coming up in the next few weeks, my question is how do we get a successful build? I followed the instructions listed here: http://richardsbraindump.blogspot.com/2009/11/how-to-build-vs2010-solutions-using.html, however the build fails. My pathway towards the solution: had me put VS 2010 on Alice, instead of turning off the build service and turning it back on, I simply restarted the server*, modified a pathway as it was listed (previously "" and Norton Ghost 2003 gave me a problem with that in the beginning).
*denotes possible problem
What happens: CI_X.1 - Failed -
Any help (including something as simple as analyzing the summary to own experience with the two environments would be much appreciated)
Update: found this error:
C:\Program Files\MSBuild\Microsoft\VisualStudio\TeamBuild\Microsoft.TeamFoundation.Build.targets(373,7): error MSB4131: The "Reason" parameter is not supported by the "GetBuildProperties" task. Verify the parameter exists on the task, and it is a gettable public instance property.
We are using VS2010 RC connecting to TFS 2008.
The solution we've done for now is to modify the Microsoft.TeamFoundation.Build.targets file that was located in C:\Program Files\MSBuild\Microsoft\VisualStudio\TeamBuild folder.
Remove the line <Output TaskParameter="Reason" PropertyName="Reason" />
This appears to be an issue where its a new feature on TFS2010 that was added to the build.targets file. Since the feature doesn't appear to be in TFS2008 and the Microsoft Connect has closed the ticket, it seems to be the best option for now.
This of course leads to another bug that raises the error: MSB4131: The "AssociatedChangesets" parameter is not supported by the "GenCheckinNotesUpdateWorkItems" task.
From the Microsoft Connect, this will be fixed in the RTM. The workaround is to add <SkipGetChangesetsAndUpdateWorkItems>true</SkipGetChangesetsAndUpdateWorkItems> to your TFSBuild.proj file.
And then I was finally able to build .NET 4.0 solution under TFS2008.