Say (100% hypothetically) that I've accidentally added a unit test project as project type "Class library" to a VS2010 solution. I've then added the assemblies needed to run it as a Unit Test project, but MSTest won't pick up on it when I hit "Run all tests in solution". What are the criterias here?
I had a couple of theories, which all have failed so far:
Something in the .testsettings file (no references to any assemblies here as far as I can see)
Something in the .SLN file (can't find anything)
Something in AssemblyInfo.cs (no, it's not)
Implict by referencing the (...)UnitTestFramwork.dll (Obv not)
Anyone?
In the project file, there's an XML element with the name ProjectTypeGuids, that holds a few GUIDs that denote test project. Example as follows.
<Project>
<PropertyGroup>
<ProjectTypeGuids>{3AC096D0-A1C2-E12C-1390-A8335801FDAB};{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}</ProjectTypeGuids>
</PropertyGroup>
</Project>
Here's a list of known project type GUIDs for Visual Studio 2010: http://onlinecoder.blogspot.com/2009/09/visual-studio-projects-project-type.html
In the example above, it shows the project to be of type Test and Windows (C#).
In case it helps anyone I had the opposite problem - I added a project as Unit Tests mistakenly. To change the type back to a normal Class Library I just removed the ProjectTypeGuids tags mentioned in the other answers altogether, presumably VS put back the correct ones.
In Solution Explorer, right-click the project name and select Unload Project.
Then right-click the project name again and select Edit ProjectName.csproj.
Locate the ProjectTypeGuids element and following code.(If you will not find the ProjectTypeGuids element, just insert it)
<Project>
<PropertyGroup>
<ProjectTypeGuids>{3AC096D0-A1C2-E12C-1390-A8335801FDAB};
{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}
</ProjectTypeGuids>
</PropertyGroup>
</Project>
.
Save the changes, right-click the project, and then select Reload Project.
Related
I have a Visual Studio solution with the project I am working on (main project). The solution references a different project that main project requires as a dependency (dependency project).
The solution and the main project are located in one directory:
/mycode/main_project/main_project.sln
/mycode/main_project/main_project.csproj
The dependency project is located in a different directory:
/mycode/dependency_project/dependency_project.csproj
Both of these projects are under source control. I want to create some kind of configuration file for main project that is not under source control, so that another developer could clone both projects wherever they want and simply edit a non-source-controlled configuration file to allow the main project's solution to locate dependency project.
Currently, main solution locates dependency project using a relative path:
../dependency_project/dependency_project.csproj
If I enforce that all developers should clone these two projects to the same directory, the main solution will successfully link to the dependency project and everything will be happy. However, I would prefer that another developer can place the dependency project wherever they want.
Does Visual Studio 2019 Community support any kind of solution configuration file which could be kept ignored by version control and used to resolve the path to the dependency project?
Solution files are very primitive and do not offer such a dynamic functionality. However, if you don't need dependency_project to show up in the IDE, you can still reference it from main_project.csproj and that does give you more options. It should still build fine even if the project doesn't show up in Solution Explorer.
For example, you could reference it through an environment variable, with a default expected path if that variable isn't set:
<PropertyGroup>
<DependencyProjectPath Condition=" '$(DependencyProjectPath)' == ''>../dependency_project/dependency_project.csproj</DependencyProjectPath>
</PropertyGroup>
<ItemGroup>
<ProjectReference Include="$(DependencyProjectPath)" />
</ItemGroup>
If you set the DependencyProjectPath environment variable before opening the solution (because VS inherits the environment variables from where it was launched), it will override the default setting here (based on the Condition attribute).
Is it possible to use an external build system for VC++ 2013?
I want Visual Studio do nothing but build by invoking my build tools.
I am thinking about something like this:
Put all build command in batches.
Invoke a project-level build batch by right clicking the project and choose build.
Invoke the a solution-level build batch by right clicking the solution and choose build.
Is there some walk-through tutorial? I searched a lot but no luck.
ADD 1 - Some progress...
After briefly reading about the MSBuild process, I tried as below.
First, I edit the *.vcxproj project file. I change the DefaultTargets from Build to MyTarget.
<Project DefaultTargets="MyTarget" ToolsVersion="12.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
Then I add a new target named MyTarget:
<Target Name="MyTarget">
<Message Text="Hello, Bitch!" />
</Target>
I hope this can bypass the VS2013 built-in built process and only carry out my own batch.
It works well on command prompt:
But in Visual Studio, when I right click the project and choose build command, it gives me a lot of link errors.
How to avoid these link errors? Since my batch can take care of all the build process, I don't need Visual Studio to do the link for me.
ADD 2
It seems these link errors show up because I include the *.c files with the ClCompile tag as below.
<ItemGroup>
<ClCompile Include="z:\MyProject1\source1.c" />
<ItemGroup>
Since I don't want VS2013 to invoke the compiler, I change it to <ClInclude> tag, the link errors disappeared, but the symbol resolution is not working... Seems I shouldn't change the tag.
ADD 3
Here's another way to compile without linking.
Is it possible for Visual Studio C++ to compile objects without linking
Seems it doesn't have the symbol resolution issue. But I still cannot invoke an external batch by click build/rebuild/clean.
You might want to look into Visual Studio's makefile projects (in the Visual C++/General project templates category).
You get to specify what commands to execute for each type of build (clean, build, rebuild). The command can invoke a make, run a batch file, or invoke some other build tool. It just executes a command. The commands can contain various macros that VS provides (similar to environment variables) so the command can be parametrized for things like making a target directory based on the solution or project name or type (debug vs. release).
(Michael Burr's reply pointed out a better direction, i.e. a better VC++ project template. You can combine my answer and his.)
Finally, I solved this issue!
The trick is the so-called target overriding. The Visual Studio context menu items Build\Rebuild\Clean correspond to MSBuild targets named Build\Rebuild\Clean, respectively. We just need to override them in the *.vcxproj file.
Such as this:
DO REMEMBER that:
The last target seen by MSBuild is the one that is used — this is why
we put the at the end of the existing *.vcxproj file.
And in the override.proj, do whatever you like as below:
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Target Name="Build">
<Message Text="Build override!" />
<Exec Command="kickass.bat" />
</Target>
</Project>
The following 2 links are good reference:
Hack the build
Hijacking the Visual Studio Build Process
Note that:
The 1st link take a CSharp project as example, but ALSO works with VC++ project.
The 2nd link doesn't work for VC++ project but the rational is similar. If you didn't include the Microsoft.Cpp.targets, you will see the following error when loading the project:
ADD 1
As I tried, we don't need another overrride.proj file. We can just place the specific target at the end of the *.vcxprj file. Such as below:
ADD 2
With target overriding mentioned above, I can run my customized bat file with project's Build/Rebuild/Clean commands. But I noticed that when I run solution's Build/Rebuild/Clean commands, I think it is just following some kind of project dependency order to build each project respectively, which is not exactly equivalent to what I want for an overall build in my scenario.
My current workaround is to create a dummy project and use it to trigger a batch for my overall build.
It happened in VS2010 that when creating project, .csproj file didn't generate some tag ProjectTypeGuids in the first PropertyGroup.
This had consequence that I couldn't see in TestView window any MS unit test in that project, nor execute it.
I copied ProjectTypeGuids from some other .csproj file where tests worked, and it worked, by explanation of MoCapitan in:
MSTest Not Finding New Tests
Does anyone knows what is ProjectTypeGuids, why UnitTests are not working without it and what is the reason for VS to generate or to omit it?
ProjectTypeGuids is list of "guid that identifies project type". So if you are missing "this is Unit test project" guid than default VS infrastructure will not try to look for tests in that project (other test runners like R# may still run such tests).
If you created project as regular "class library" (instead of "Unit tests project") than the guids will be missing.
Partial list of types: http://www.codeproject.com/Reference/720512/List-of-Visual-Studio-Project-Type-GUIDs
I have an ASP.NET MVC 4 app developed in VS 2012. The app consists of a main project (MyProject), a unit-test project (MyProject.Tests), an Azure deployment project (MyProject.Azure), and a couple of general-purpose library projects.
When I right-click on either the solution or the main project and select Manage NuGet Packages, I see a bunch of Microsoft updates that have apparently become available in the last month or so. If I click on the Update All button then the updates are apparently installed without any obvious problems, but when I build the solution I get this error message TWICE:
warning : All projects referencing MyProject.csproj must install nuget package Microsoft.Bcl.Build
Ok, so I have two projects that reference MyProject: MyProject.Tests and MyProject.Azure. I can right-click MyProject.Tests, select ManageNuGet Packages, and add Microsoft.Bcl.Build. That gets rid of one of the two warnings. But VS does not give me an option to manage NuGet packages for the MyProject.Azure project.
How do I add the Microsoft.Bcl.Build package to the Azure deployment project?
EDIT:
Thanks to user swell, I now know that a Microsoft Connect issue for this problem has been opened here.
The answer provided by TheESJ is correct, however the wording wasn't clear to me. Since I cannot comment on the answer, I will provide more details here. Specifically, I was having this problem with an Azure project and the following workaround was required to make the warning go away:
When you double-click the warning in VisualStudio, you will be taken to the BclBuildValidateNugetPackageReferences target in the Microsoft.BclBuild.targets file. Above the actual target element, you should find a large comment block that talks about disabling the project reference checks. Since Azure projects cannot have any library references, it is impossible for those Azure projects to fulfill the requirements of this particular build target.
The solution? Disable reference checking from the Azure project since it is impossible to actually add a nuget package reference.
EXAMPLE
So, assume we have two projects: MyAzureProject.ccproj which references MyProject.csproj. Follow these steps:
Right-click on "MyAzureProject" in the Solution Explorer and select "Edit Project File."
Find the project reference to "MyProject." It should look something like:
<ProjectReference Include="..\MyProject\MyProject.csproj">
<Name>MyProject</Name>
<Project>{1d99490e-d140-4897-9890-238e673a5864}</Project>
...
</ProjectReference>
Add the following element inside of the ProjectReference element:
<Properties>SkipValidatePackageReferences=true</Properties>
Your project reference should now look like this:
<ProjectReference Include="..\MyProject\MyProject.csproj">
<Name>MyProject</Name>
<Project>{1d99490e-d140-4897-9890-238e673a5864}</Project>
...
<Properties>SkipValidatePackageReferences=true</Properties>
</ProjectReference>
Right-click on "MyAzureProject" in Solution Explorer and choose "Reload Project."
You should now be able to rebuild and the error should be gone.
If you double click the warning it gives you instructions for disabling the warning.
It is safe to disable for projectreferences from projects that don't yet support Nuget.
See below portion in bold copied from Microsoft.Bcl.Build.targets.
BclBuildValidateNugetPackageReferences
This target can be disabled for a project reference by setting SkipValidatePackageReferences=true for the reference:
<ProjectReference Include="..\pcl\pcl.csproj">
<Project>{664a9e98-fac7-4567-a046-0dde95fddb48}</Project>
<Name>pcl</Name>
<Properties>SkipValidatePackageReferences=true</Properties>
</ProjectReference>
I faced the same issue and was trying to update Microsoft.Bcl.Build.targets; which did not help.
After some investigation found that .csproj file of the Azure Service project must be modified to include <Properties>SkipValidatePackageReferences=true</Properties>.
This was not apparent from the answer of #TheESJ and so decided to post separate answer. Thanks to #TheESJ.
I encountered this issue a number of times, and the Properties method does indeed work, but when dealing with a Wix project, I had to do the following instead:
<AdditionalProperties>SkipValidatePackageReferences=true</AdditionalProperties>
When I used the Properties Xml node, I got a new error:
The OutputPath property is not set for project
'MyInstallerProject.csproj'. Please check to make sure that you
have specified a valid combination of Configuration and Platform for
this project. Configuration='Debug' Platform='x86'. This error may
also appear if some other project is trying to follow a
project-to-project reference to this project, this project has been
unloaded or is not included in the solution, and the referencing
project does not build using the same or an equivalent Configuration
or Platform.
After failing to resolve the issues with any of the above answers, I simply followed the instructions contained within the Microsoft.Bcl.Build.targets file (displayed after double clicking on the error in the build output window).
I unloaded my project (referencing Azure packages), encountering the error. Edited the project file and inserted the following...
<PropertyGroup>
<SkipValidatePackageReferences>true</SkipValidatePackageReferences>
</PropertyGroup>
...at the top of the project file before the first PropertyGroup.
I finally figured out that Visual Studio keeps track of how you create a project (in other words which project template you select initially) and filters your options later based on that initial decision. The information is kept in the *.csproj file as a <ProjectTypeGuids> element.
Other than just editing the *.csproj file, is there a "right" way to change a project type for an existing project?
Considering the significance of that setting it seems likely there's a place in the GUI to change it, but I couldn't find one. Thanks!
Small correction: Visual Studio does not keep track of the project template used to create a project. The project system is largely unaware of the initial template used for a project. There are several items in the project system (Project Type for instance) which have the same name as specific templates but this is a coincidence and the two are not definitively corrected.
The only thing that can really be changed in terms of the project type is essentially the output type. This can have value Class Library, Console Application and Windows Application. You can change this by going to the project property page (right click Properties) and change the Output Type combo box.
It is possible to have other project types supported by the project system but they are fairly few and are not definitively associated with a project template.
In visual studio the project type is stored inside the .csproj XML file as GUID. You have to change the GUID to define the new project type you want.
check http://www.mztools.com/Articles/2008/MZ2008017.aspx for some of the availbale GUIDs
Why do you want to change this?
I would just add another project to the solution with the one you want, move the files, then remove the original project.
You can modify it in the .csproj file to change the project type, for instance from .Net Core to .Net Standard. Just by changing the content of blabla you are done with the changes.
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>netstandard2.0</TargetFramework>
<AssemblyName>...</AssemblyName>
<RootNamespace>...</RootNamespace>
</PropertyGroup>
</Project>
But you should take note if you use some external packages, the packages might not be compatible with the new project type. So, you may need to get the compatible packages.
I needed to add WPF support to a project of type "Class Library (.NET CORE)" in this way:
edit YourProject.csproj (double click on it) and modify <Project Sdk="Microsoft.NET.Sdk"> to <Project Sdk="Microsoft.NET.Sdk.WindowsDesktop">
add <UseWPF>true</UseWPF> in the group <PropertyGroup>
rebuild YourProject
Now you can add a WPF Window