Visual Studio 2010 had a feature with which it was possible to generate a test method for each public method or property of a class. Even I know that the result was more or less use less, I was wondering if this feature still exists in VS2012 because I didn't find it.
This feature has been removed from VS 2012.
Try this plugin:
http://blogs.msdn.com/b/willy-peter_schaub/archive/2013/06/13/announcing-the-unit-test-generator-visual-studio-extension-beta.aspx
I miss the option to configure the structure in which it creates tests but besides that it works fine.
Related
I use ResXFileCodeGeneratorEx for generating ids. This was working till the time I used Visual Studio 2010 IDE but it is not working for Visual Studio 2017.
Please help for the same.
Extension for Visual Studio 2019 can be found here
Extension for Visual Studio 2017 can be found here
The deleted answer to this question pointed to the location of a newly built ResXFileCodeGeneratorEx but was deleted because it only contained a single link and no context. I'm not the original answerer, but figured that it may still be valuable to have this information:
It seems to have been renamed to ResXCodeFileGeneratorEx, and if you search through the menu in Visual Studio under Tools > Extension and Updates, you need to search for "Extended Strongly Typed Resource Generator".
However, the internal name is still the same, so the Custom Tool action should remain ResXFileCodeGeneratorEx.
I'm not aware whether or not it works on Visual Studio 2019, but since the original source is still around, it oughtn't be too hard to resolve that yourself if you need it.
To install it, simply doubleclick the VSIX file, it will popup with the VS Version Instance Selector, where you can select to which of your VS 2017 instances (pro, community, preview) you want to install the extension to.
I ran into an issue this morning after upgrading to Visual Studio 2012.
Specifically, I have a class that extends ExpectedExceptionBaseAttribute. The test passes in Visual Studio 2010 but fails in 2012.
The issue on Microsoft Connect is here which has been closed as "by design" but in my opinion, this is a bug. Whilst there is a resolution provided by Microsoft, it requires me to force the new version of MSTest into a legacy mode.
I have not included sample code here because there is a small sample project available for download on the Connect issue.
If, as they state in the comments, the new version of MSTest is leaner and more performant, then I want to use it without putting it into a legacy mode.
So the question is how do get it to work without resorting to that?
This appears to be fixed in VS2012 Update 3.
Me and my partner are both sharing a c++ solution via subversion.
He is using Visual Studio 11 and I am using Visual Studio 2010.
After the first time he commited and i updated, i get the following error:
Error 31 error MSB8008: Specified platform toolset (v110) is not installed or invalid. Please make sure that a supported PlatformToolset value is selected.
also, in header files i get the following error on #include <stdio.h>:
error: cannot open source file "stdio.h"
I am guessing this is a compatibility issue. How can we resolve this?
In Visual Studio 11 there is a property option that allows you to specify the platform toolset.
Platform Toolset v110 is used by default if you create a new project starting from Visual Studio 11, but if can change it to v100 that is the one used by Visual Studio 2010.
.sln and .vcxproj files saved in Visual Studio 11 are not backward-compatible with VS2010. Even if they were compatible, eventually you'd step across a code which is compilable in VS11 but not in VS10.
The best (and probably the only) way is to agree on using exactly the same development environment.
A bit late in the discussion, but since you're using source control, you can remove the project and solution files from the repository and just share source code. Obviously, if you add new modules and such to a project, you'll have to manually add them in the other solution, but at least you wouldn't have to worry about this incompatibility. If you wanted to get down to it, the application can be built from the command line using just the compiler and linker switches, which tend to be far more compatible between revisions. Finally, you could use another build tool (besides MSBuild), that remains compatible across studio versions.
If you decide to remove the solution and project files, one thing to consider is saving a copy of the original YourApp.sln as YourApp.sln.2010. Then you'll have something to seed future solutions from, but updates to projects and solutions will all need done from VS 2010 and the file then copied to their .2010 version and maintained manually.
If SVN has support for patches, or if you're willing to run quilt externally (or if you switch to mercurial, you can use the MQ extensions), you can create the patch files to convert from 2010 to 2011 and remove the upgrade patche(s) before synch.
Drake's solution didn't work for me as the properties for all projects in the solution were already correctly set to v100. However, the fix that did work was to clean the builds and remove all other files that weren't source files or project files. I think it was probably removing the files projname.vcxproj.user that fixed it, as perhaps the toolchain preference was somehow overriden in the user preferences.
We've been using VS2008 and soon will be upgrading to VS2010. I have been using MSTestExtensions for it's database rollback feature for integration tests via MSTest. It seems the open source project has not been having much contribution in the last 2-3 years. Thus, I was curious if anyone has tried to use it with VS2010. Does it still work?
Seeing that you can download the source code to the MSTestExtensions project, it might be worth getting the source and building it in VS 2010. Since the MSTest functionality in VS 2010 has not changed that much since VS 2008 (from what I've read), I would say you have a good possibility of getting the code to build. The resulting binaries could be used for your VS 2010 development (hopefully! :)
I can now verify that the 2008 MSTestExtensions dll does indeed work with Visual Studio 2010.
The only thing is it didn't show up in the list of .net references so I had to manually browse to where it was installed. In my case that was to C:\Windows\assembly\GAC_MSIL\MSTestExtensions. Just add a reference to the version 2.0 dll (VS 2008 version) and it will work as expected.
I have a huge Visual Studio 2010 solution. I work with Visual Studio 2005, so I want to convert the solution to the desired version. Basically, it's a portable C++ code so it should compile on Visual Studio 2005 too. Changing the version in the *.sln file doesn't help because the *.vcxproj format is completely different from the old *.vcproj format.
Recreating the solution by hand is not an option because of its size. Also there may be some non-default compiler flags, dependencies, etc. that I don't know of (and I can't look through ALL this XML junk that I don't understand).
There is already a related question on How Do I Downgrade a C++ Visual Studio 2008 Project to 2005. However, the utility suggested there supports at most Visual Studio 2008.
Any suggestions?
It really totally sucks, that every proprietary IDE today thinks it needs to create its own project file format.
"Dear IDE developers, just use Makefiles and create a nice GUI for it so that also people without Makefile knowledge can use it!" In VS6 it was at least possible to import/export Makefiles, but not today anymore. And it was possible to use nmake for automated builds. No IDE needed to be installed, just the toolchain which could be grabbed by a simple checkout without installation.
I use CMake now. It's free, it's cross-platform, it is well supported in free IDEs like KDevelop, QtCreator, etc. It can generate Makefiles and Visual Studio projects.
So you maintain only one project source, the CMakeLists.txt file and can work with any IDE. No pain with different versions of Visual Studio or with other proprietary project file formats.
This way you can generate or VS projects for developing and you can generate Makefiles for commandline builds using nmake like in the good old days.
BTW, it's much easier to change settings in a CMakeLists.txt than clicking through various GUI dialogs. But this is a matter of personal preferences.
In my work made a utility which utilized the EnvDTE.dll and scanned a vcproj-file and optionally all vcproj-files within a sln-file. It compared all settings with a "template" and would issue a warning or optionally update the setting to correct values. We used this utility so that settings would be verified to be correct and consistent throughout all projects. I haven't updated the utility to 2010 yet due to other priorities.
EnvDTE hasn't changed much from Visual Studio 2008 to Visual Studio 2010. Perhaps it is possible to create a simple utility which opens the vcxproj-file using DTE100 and saves it using DTE90, or earlier.
Easiest way is probably to create a new project in VS 2005, and use the add existing item dialog to add the code to the project. I'd suggest using 'Empty Project' as the project type, so you don't have a lot of rubbish autogenerated for you that you'll just delete anyway.
I haven't tried it, but this looks promising:
http://www.emmet-gray.com/Articles/ProjectConverter.htm
edit: Nope, not promising, sorry :-(