I am using Visual Studio 15.3.5 and Microsoft.NET.Sdk.Functions 1.0.6.
I can run tests fine, but when I analyze the tests with Code Coverage the assembly which contains the Azure Functions is not analyzed. It is not listed in the Code Coverage assembly list. Other assemblies are listed, only the Azure Functions assembly is omitted.
Have anyone got it working?
The reason is that for new project types, the default <DebugType> is portable, which means that the pdb's generated would not have required info needed for CodeCoverage.
Here is how you can change this: in your .csproj, add <DebugType>full</DebugType> to the <PropertyGroup>. e.g. you should have:
<PropertyGroup>
<TargetFramework>net461</TargetFramework>
<DebugType>full</DebugType>
</PropertyGroup>
Or you can change this from VS:
go to properties on the project
go to the build tab, then the “Advanced…” button at the bottom
there’s a dropdown for Debugging Information. Setting that to “Full” updates the project with the necessary property
Related
I have a C# class library project which I consume from a C++ project. This works perfectly well when:
the C# project has TargetFramework set to netstandard2.0
the C++ project has TargetFrameworkVersion set to v4.7.2
However, I now need to upgrade the C# library to net5.0...
the C# project has TargetFramework set to net5.0 (using new style project file)
the C++ project has TargetFrameworkVersion set to v5.0
and receive this error....
C:\Program Files\Microsoft Visual
Studio\2022\Preview\MSBuild\Current\Bin\amd64\Microsoft.Common.CurrentVersion.targets(1806,5):
error : Project '..\cslib\cslib.csproj' targets 'net5.0'.
It cannot
be referenced by a project that targets '.NETFramework,Version=v5.0'.
Note that it's not possible to set the TargetFrameworkVersion for the C++ project to "net5.0" or "net5.0-windows" since that results in a project load error:
It's not clear that "v5.0" is the correct TFM for a C++/vcxproj format file - it's possible msbuild is just falling back to v4.7.2 by default but I can't think of a better alternative.
Is there a way to accomplish this? It seems like it should be possible to target net5.0 in a C++ project by now. (I'm using Visual Studio 2022 Preview and PlatformToolset is set to v143 which is the latest).
It's a bit tricky, but the following should help:
If using the GUI, the following settings need to be made in properties: Under "Root->Extended" setting "Common language runtime support": "Net Core runtime support /clr:core" and ".NET Core Target framework": ".NET 5.0" (you might need to click "apply" after choosing the first, to get the possible settings in the second box to update)
In the .vxcproj, this results in:
...
<PropertyGroup Label="Globals">
<TargetFrameworkVersion>v5.0</TargetFrameworkVersion>
<Keyword>ManagedCProj</Keyword>
<TargetFramework>net5.0</TargetFramework>
...
</PropertyGroup>
and (once for each build configuration):
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Release|x64'" Label="Configuration">
<ConfigurationType>DynamicLibrary</ConfigurationType>
<CharacterSet>Unicode</CharacterSet>
<PlatformToolset>v142</PlatformToolset>
<CLRSupport>NetCore</CLRSupport>
...
</PropertyGroup>
Note that it is not possible to create C++ exes in .NET Core. C++/CLI projects must be libraries and cannot contain the main entry point (create a stub-loader C# project if you have to).
You may then experience:
error NETSDK1145: The Apphost pack is not installed
This documentation suggests this can be overcome by modifying the project file but if that does not work, a global.json file can be added in the solution root folder to point to the desired SDK.
How does Visual Studio (2015) work with external tools like NPM and Typescript compiler (tsc.exe) etc.? I guess, at the time of building the solution or project, something must be telling MSBuild to run these extra tools. I want to understand this under the hood operation.
It all depends...
Visual studio has multiple services and features that interlink here:
Language Services - Visual Studio can be extended with so called language services, these provide intellisense, syntax analysis, highlighting etc. For Javascript and Typescript Microsoft provides a Language service that provides such information.
MsBuild - Underneath most of Visual Studio projects lives an MsBuild project. If you search your Program files directory you'll find an MsBuild folder and underneath that there are a number of target files. This includes one for Typescript which will transform your .ts files during build. These targets files either directly use the exec MsBuild task to run tools or provide a custom MsBuild task in the form of a .NET Assembly that implements specific interfaces. These tasks can either implement the required action themselves or shell out to a tool to have it perform the action.
Roslyn - For C# and VB.NET the parsing of the projects and the background compilation of the sources is handled by a new compiler called Roslyn. This actually runs in the background while you type and has a very powerful in-memory model of all your code in your project. Roslyn supports add-ins as well in the form of analyzers and refactor action that either provide the user with feedback on common errors or provide ways to automatically rewrite/change the code.
Task Runner - The Visual Studio Task Runner is a plugin for Visual Studio that first shipped as an extension and is now part of Visual Studio. It reacts to events in the IDE (build, test, etc) and can associate actions in your package.json or grunt or bower etc scripts. The plugin will make sure your script commands are executed at the right point in time during the builds.
Test Runners - The Visual Studio Test Window has support for extensions as well, so the Mocha and the Chutzpah extension in your project will be picked up and during the test execution these plugins will be asked to first list and later execute the tests. These runners act as a kind of proxy, feeding back the list of tests and their status after execution.
Custom extensions - There are many other ways in which some vendors extend Visual Studio by providing a generic extension. These extensions may contain any of the above elements or may just listen to the events generated by Visual Studio while you do your work and react on them.
You can see the references to the typescript items if you open the .csproj
with a text editor (or from visual studio : unload the project, right-click on the project and choose edit myproject.csproj )
You'll see the typescript resources :
<ItemGroup>
<TypeScriptCompile Include="src\config.ts" />
the target for the build :
<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\TypeScript\Microsoft.TypeScript.targets" Condition="Exists('$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\TypeScript\Microsoft.TypeScript.targets')" />
The external tools, are configured in Tools/Options :
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.
I'm trying to add some simple MSBuild tasks to a Visual Studio project (VS 2012 Express) - specifically, to create a subdirectory then copy some files to a subdirectory of the output directory ready for packaging.
I see that VS supports custom build steps, which are command-line invocations. However, since VS is based on MSBuild it should be possible to add these directly as MSBuild tasks like the Copy Task in the AfterBuild pre-defined target.
What I can't find is any way to actually add such tasks within the framework of Visual Studio. The documentation only talks about it from an MSBuild perspective, not how it works within Visual Studio's UI. It also doesn't seem to discuss the properties that refer to build output etc there; presumably they're just those used by msbuild its self.
Is there support for MSBuild task management in Visual Studio's UI and it's just crippled out of my Express edition? Or do I have to go hack the project file XML to add MSBuild tasks? Is that supported and the way it's supposed to be done?
I'm used to working with Eclipse and Ant or Maven, where all this is supported within the IDE, though of course you can hack the XML directly. Finding no UI at all for MSBuild task management in Visual Studio is quite confusing. Am I missing the obvious or crippled by using the freebie edition?
For C++ projects, you can use the property
<CppCleanDependsOn>DeleteOutputs;$(CppCleanDependsOn)</CppCleanDependsOn>
instead of defining the BeforeClean target like you did.
From what I read, CallTarget is to be avoided. In your example, you should use DependsOnTargets to do that, as you see in many dummy targets in the MS supplied files. The analogous mechanism of a function where a target just "calls" other targets is done with DependsOnTargets. The flow is not really the same as procedural programming.
Intellisense: I never use it. Is that true for conditional AdditionalIncludeDirectories in the props file only? Go ahead and edit the entry in the proj file where the IDE put it, if you edit the property in the IDE with just one configuration chosen.
(After a bunch more reading I found out how this works):
Visual Studio doesn't seem to expose advanced MSBuild project editing, even though modern vcxproj files are just MSBuild project files with a bunch of extra labeled properties and other entries for Visual Studio IDE specifics. So you have to hack the project XML.
To make it cleaner, only add one line to your actual vcxproj file - an include of a .targets file that contains the rest of your build customisations. e.g, just before the end of the project file, insert:
<Import Project="pg_sysdatetime.targets" />
</Build>
Now create your .targets file with the same structure as any other MSBuild project. Here's mine from the project I've been working on:
<?xml version="1.0" encoding="utf-8"?>
<Project DefaultTargets="Build" ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<!-- MSBuild extension targets for Visual Studio build -->
<PropertyGroup>
<DistDir>pg_sysdatetime_pg$(PGMAJORVERSION)-$(Configuration)-$(Platform)</DistDir>
</PropertyGroup>
<ItemGroup>
<DocFiles Include="README.md;LICENSE"/>
<ExtensionSourceFiles Include="pg_sysdatetime--1.0.sql;pg_sysdatetime.control"/>
<ExtensionDll Include="$(TargetDir)\pg_sysdatetime.dll"/>
</ItemGroup>
<Target Name="CopyOutputs">
<Message Text="Copying build product to $(DistDir)" Importance="high" />
<Copy
SourceFiles="#(DocFiles)"
DestinationFolder="$(DistDir)"
/>
<Copy
SourceFiles="#(ExtensionDll)"
DestinationFolder="$(DistDir)\lib"
/>
<Copy
SourceFiles="#(ExtensionSourceFiles)"
DestinationFolder="$(DistDir)\share\extension"
/>
</Target>
<Target Name="DeleteOutputs">
<Message Text="Deleting $(DistDir)" Importance="normal" />
<Delete Files="$(DistDir)"/>
</Target>
<!-- Attach to Visual Studio build hooks -->
<Target Name="BeforeClean">
<CallTarget Targets="DeleteOutputs"/>
</Target>
<Target Name="AfterBuild">
<CallTarget Targets="CopyOutputs"/>
</Target>
</Project>
This can contain whatver MSBuild tasks you want, grouped into targets. It can also have property groups, item groups, and whatever else MSBuild supports.
To integrate into Visual Studio you add specially named targets that invoke what you want. Here you can see I've defined the BeforeClean and AfterBuild targets. You can get the supported targets from the VS integration docs.
Now, when I build or rebuild, a new directory containing the product DLL and a bunch of static files is automatically created, ready to zip up. If I wanted I could add the Nuget package for MSBuild Community Extensions and use the Zip task to bundle the whole thing into a zip file at the end too.
BTW, while you can define properties in your .targets files it's better to define them in property sheets instead. That way they're visible in the UI.
I'm using VS2010 Pro, and it doesn't expose the AfterBuild target, at least in C++ projects which is what I'm doing. As you see, it does have the "Events", which according to what I've read are for backward compatibility with converted projects from VSBuild. I agree, a MSBuild task rather than a command script is the way to go.
Forget the UI. It's made to support free editing of the XML files, and continue using the UI too as it respects what you had in there and uses labels for its own stuff so it can find it to update it.
But to keep it neat, you could use a property page; a stand-alone XML file with *.props name, and put what you want in it. Then add that props file to the projects using the UI. You won't hand-edit the project file that the UI is maintaining, and it won't touch the props file unless you go through the property manager view and open it explicitly.
Oh, I also recall seeing additional standard targets something like Package and Publish. Maybe those are not used on your project type, but you could use those entry points anyway.
I've added a new build target to my C++ Visual Studio project (vcxproj).
This target runs a custom tool when the project is built. The tool processes specific files on the solution according to the ContentType and ItemType I specified.
This works well with project actions such as "Build" and "Clean".
Now I would like to support an action equivalent to "compile", i.e. right click on a file in the Solution Explorer and select to process this specific file with my custom tool (the same way "compile" runs "CL" for "C/C++ Code" file types).
I know I could add a Visual Studio macro to do this. This is not a good solution for me because it's harder to deploy for many users.
A better solution is to customize the vcxproj (or files imported by it).
I wonder if it's possible to add a "compile" like action in the menu (or change the "compile" behavior for file types other than "C/C++ Code") through msbuild targets scripts or PropertyPageSchema.
UPDATE: I've started a discussion on MSDN forum. Got some answers from a Microsoft moderator that helped clearing up some things, but the problem is still unsolved.
UPDATE (2016), for VS2015
AvailableItemName seems to solve this on VS2015. For example, I have a custom target to process Excel files.
On the targets file:
<ItemGroup>
<PropertyPageSchema Include="$(SolutionDir)\ExcelOptions.xml" />
</ItemGroup>
<ItemGroup>
<AvailableItemName Include="Excel">
<Targets>ProcessExcel</Targets>
</AvailableItemName>
</ItemGroup>
On the options file:
<FileExtension Name=".xls" ContentType="Excel"/>
<ContentType Name="Excel" DisplayName="Excel File" ItemType="Excel"/>
<ItemType Name="Excel" DisplayName="Excel File"/>
Now Compile is accessible on the Solution Explorer context menu after selecting an excel file, and CTRL-F7 works as well (for files that can be edited on VS, not for excel files)