Setting/Configuration for external nuget services on AppHarbor - appharbor

Is it possible to configure nuget endpoints for other nuget services other than the default location on AppHarbor? My current build fails because AppHarhor cannot find the nuget references as they don't exist on the default nuget server.

If you add your custom package feed in the NuGet.targets file like this:
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<ItemGroup Condition=" '$(PackageSources)' == '' ">
<PackageSource Include="myurl" />
</ItemGroup>
</Project>
... you should be fine.

Related

ToolsVersion in Visual Studio 2019

I am doing the migration of several projects from VS2010 to VS2019. Those projects have Tools Version 4 in their vcxprojs:
<Project DefaultTargets="Build" ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
Target VS is VS2019 v16.5.0, MSBuild version is 16.5.0.12403, so I am trying to set ToolsVersion to 16.5:
<Project DefaultTargets="Build" ToolsVersion="16.5" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
But it seems that MSBuild doesn't like it:
1>Building with tools version "Current".
1>Project file contains ToolsVersion="16.5". This toolset may be unknown or missing, in which case you may be able to resolve this by installing the appropriate version of MSBuild, or the build may have been forced to a particular ToolsVersion for policy reasons. Treating the project as if it had ToolsVersion="Current".
Despite builds are anyway successful, I care about this message. What can be wrong here?
UPD:
Providing simplified example of structure of projects:
common props:
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<ShouldUnsetParentConfigurationAndPlatform>false</ShouldUnsetParentConfigurationAndPlatform>
</PropertyGroup>
<PropertyGroup Label="Globals">
<WindowsTargetPlatformVersion>10.0</WindowsTargetPlatformVersion>
<DotNetFrameworkVersion>v4.0</DotNetFrameworkVersion>
</PropertyGroup>
<!-- Other common variables-->
</Project>
cpp props:
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup Label="Configuration">
<ConfigurationType>DynamicLibrary</ConfigurationType>
</PropertyGroup>
<PropertyGroup>
<TargetExt>.dll</TargetExt>
</PropertyGroup>
<PropertyGroup Label="Configuration">
<PlatformToolset>v142</PlatformToolset>
</PropertyGroup>
<Import Project="$(VCTargetsPath)\Microsoft.Cpp.Default.props" />
<Import Project="$(VCTargetsPath)\Microsoft.Cpp.props" />
<Import Project="$(UserRootDir)\Microsoft.Cpp.$(Platform).user.props" Condition="exists('$(UserRootDir)\Microsoft.Cpp.$(Platform).user.props')" Label="LocalAppDataPlatform" />
<Import Project="common.props" />
<-- compiler, linker settings and so on -->
</Project>
Real project:
<?xml version="1.0" encoding="utf-8"?>
<Project DefaultTargets="Build" ToolsVersion="16.5" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup Label="Globals">
<ProjectName>my_name</ProjectName>
<ProjectGuid>{my_guid}</ProjectGuid>
<RootNamespace>my_ns</RootNamespace>
<Keyword>my_keyword</Keyword>
</PropertyGroup>
<Import Project="cpp.props" />
<-- configurations (Release, Debug, x64/Win32 and so on -->
<-- project-specific compiler/linker settings -->
<-- items: cpp, heanders and so on -->
<-- references -->
<Import Project="$(VCTargetsPath)\Microsoft.Cpp.targets" />
<ImportGroup Label="ExtensionTargets">
</ImportGroup>
</Project>
Project file contains ToolsVersion="16.5". This toolset may be unknown
or missing
To solve this issue, you should do some updates.
Suggestion
1), right-click on the project on VS2019 IDE-->Retarget Projects and target this project to the Windows 10 SDK version and choose upgrade to v142.
2), Right-click your project on VS2019 IDE-->unload project-->Edit (project name).vcxproj-->change ToolsVersion="4.0" to ToolsVersion="Current"--> then reload your project
3) Right-click on your project-->Properties-->Configuration Properties-->General-->change Platform Toolset to Visual Studio 2019 v142.
----------------Update 1-----------
First of all, ToolVersion is related to the version of MSBuild that is included in the Visual Studio edition like. And in general, we do not use 16.5 in VS2019. See this link. And actually, In VS2019, the ToolVersion is set to Current.
VS2019-->Current, VS2017-->15.0,VS2015-->14.0
You cannot include a specific small version number.
This is my test result with your sample in my side and it seems that it is just like a warning:
It means that it cannot specify the Illegal toolversion 16.5.
Solution
1) Just as I said before, change toolversion to Current in Realproject.vcxproj.
2) delete the toolversion xml node in Realproject.vcxproj and in VS2019, it will automatically recognize toolversion without adding it manually.
To prove it, you can create a new VS2019 c++ project and I am sure that you cannot find toolversion node in xxxx.vcxproj file.
Then try my solution into every projects and I am sure when you finish it, the info will not appear again.

How do I choose a different Rule Set based on OutputType in Visual Studio?

Currently, I have a .Net Standard project that references StyleCop. It builds as a NuGet package and includes custom ruleset's and a custom props file. I would like the props file to apply a different rule set based on the output type of the project that references my NuGet package.
I want to add this NuGet package to a solution that includes different project types such as Class Library or Windows Forms. Different project types need a different ruleset. For example, I don't want to force documentation on a Windows Forms application but I want to force it in a Class Library project.
I am trying to do this using Conditions but the default StyleCop ruleset is always used.
I also do not know of a way to debug the project and props file to make sure the rule set is being included.
Here is my props file.
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="16.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<CodeAnalysisRuleSetLocation Condition=" '$(NuGetPackageRoot)' != '' ">$(NuGetPackageRoot)\CustomStyleCop\1.0.0</CodeAnalysisRuleSetLocation>
<CodeAnalysisRuleSetLocation Condition=" '$(CodeAnalysisRuleSetLocation)' == '' and '$(SolutionDir)' != '' ">$(SolutionDir)\packages\CustomStyleCop.1.0.0</CodeAnalysisRuleSetLocation>
<CodeAnalysisRuleSetLocation Condition=" '$(CodeAnalysisRuleSetLocation)' == '' ">$([System.IO.Path]::GetDirectoryName($(MSBuildProjectDirectory)))\packages\CustomStyleCop.1.0.0</CodeAnalysisRuleSetLocation>
</PropertyGroup>
<PropertyGroup>
<CodeAnalysisRuleSet>
<CodeAnalysisRuleSet Condition=" '$(OutputType)' == 'Library' ">$(CodeAnalysisRuleSetLocation)\CustomStyleCopClassLibrary.ruleset</CodeAnalysisRuleSet>
<CodeAnalysisRuleSet Condition=" '$(OutputType)' == 'Exe' or '$(OutputType)' == 'WinExe' ">$(CodeAnalysisRuleSetLocation)\CustomStyleCopForms.ruleset</CodeAnalysisRuleSet>
</PropertyGroup>
<ItemGroup>
<AdditionalFiles Include="$(CodeAnalysisRuleSetLocation)\stylecop.json" Link="stylecop.json" />
</ItemGroup>
</Project>
And my nuspec file.
<?xml version="1.0" encoding="utf-8"?>
<package xmlns="http://schemas.microsoft.com/packaging/2010/07/nuspec.xsd">
<metadata>
<id>CustomStyleCop</id>
<title>CustomStyleCop</title>
<version>1.0.0</version>
<developmentDependency>true</developmentDependency>
<dependencies>
<dependency id="StyleCop.Analyzers" version="[1.1.1-rc.114]" />
</dependencies>
</metadata>
<files>
<file src="stylecop.json" target="" />
<file src="Rulesets\CustomStyleCopClassLibrary.ruleset" target="" />
<file src="Rulesets\CustomStyleCopForms.ruleset" target="" />
<file src="CustomStyleCop.props" target="build" />
</files>
</package>
Is this possible to do?
Or do I need different NuGet packages for each project type?
Is there currently a way to debug msbuild? (I know it was available in the past but scrapped)

Shared Publish Profiles with User Specific variables

We have a complex visual studio publish profile for developers to deploy files. I want developers to all to use the same publish profile whilst have some variables configurable for each individual user that don't get checked in to source control. Is this possible? If so then how?
<?xml version="1.0" encoding="utf-8"?>
<!--
This file is used by the publish/package process of your Web project. You can customize the behavior of this process
by editing this MSBuild file. In order to learn more about this please visit https://go.microsoft.com/fwlink/?LinkID=208121.
-->
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<WebPublishMethod>FileSystem</WebPublishMethod>
<PublishProvider>FileSystem</PublishProvider>
<LastUsedBuildConfiguration>Debug</LastUsedBuildConfiguration>
<LastUsedPlatform>Any CPU</LastUsedPlatform>
<SiteUrlToLaunchAfterPublish />
<LaunchSiteAfterPublish>True</LaunchSiteAfterPublish>
<ExcludeApp_Data>False</ExcludeApp_Data>
<DeleteExistingFiles>False</DeleteExistingFiles>
<PipelineDependsOn>
CopyAssets;
$(PipelineDependsOn);
</PipelineDependsOn>
<publishUrl>C:\inetpub\wwwroot\local.MyApp\Website</publishUrl>
</PropertyGroup>
<Target Name="CopyAssets">
<Message Text="Inside of CopyAssets" Importance="high"/>
<Exec Command="%WINDIR%\System32\WindowsPowerShell\v1.0\powershell.exe -File "$(SolutionDir)Foundation\Scripts\Powershell\CopyAssets.ps1" $(SolutionDir) $(publishUrl)"/>
</Target>
</Project>
This is it in its simplest form. In this example I'd want developers to configure for example publish URL on a per user basis ideally in the .user file if possible or get a variable or parameter from somewhere we can pass into this publish profile.
I resolved this by creating a .wpp.targets file. I created one within the project I am publishing. This allowed me to define the Powershell I am running to run for all publish profiles.
This enabled me to allow developers to define their own publish profiles and still run the script allowing the publish URL value to be individual for each developer.
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<PipelineDependsOn>
CopyAssets;
$(PipelineDependsOn);
</PipelineDependsOn>
</PropertyGroup>
<Target Name="CopyAssets">
<Message Text="Inside of CopyAssets" Importance="high"/>
<Exec Command="%WINDIR%\System32\WindowsPowerShell\v1.0\powershell.exe -File "$(SolutionDir)Foundation\Scripts\Powershell\CopyAssets.ps1" $(SolutionDir) $(publishUrl)"/>
</Target>
</Project>
I removed the PipelineDepndsOn part from my publish profile and did it in the target file as I defined above.

VS2010 - Using <Import /> to share properties between setup projects?

Why doesn't it work to <Import /> this file, when it works when I replace the statement with just copy-pasting the three properties?
../../Setup.Version.proj
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<InstallerMajorVersion>7</InstallerMajorVersion>
<InstallerMinorVersion>7</InstallerMinorVersion>
<InstallerBuildNumber>7</InstallerBuildNumber>
</PropertyGroup>
</Project>
Works:
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<InstallerMajorVersion>7</InstallerMajorVersion>
<InstallerMinorVersion>7</InstallerMinorVersion>
<InstallerBuildNumber>7</InstallerBuildNumber>
<OutputName>asdf-$(InstallerMajorVersion).$(InstallerMinorVersion).$(InstallerBuildNumber)</OutputName>
<OutputType>Package</OutputType>
Doesn't work:
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Import Project="../../Setup.Version.proj" />
<PropertyGroup>
<OutputName>asdf-$(InstallerMajorVersion).$(InstallerMinorVersion).$(InstallerBuildNumber)</OutputName>
<OutputType>Package</OutputType>
Here the variables just evaulate to empty strings... :( I'm certain the path to the imported project is correct.
So it seems to work fine when i run msbuild from the command line, but not when I build the project inside Visual Studio. Why in the world?
I've tried to reproduce and everything works:
importme.proj
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<InstallerMajorVersion>7</InstallerMajorVersion>
<InstallerMinorVersion>7</InstallerMinorVersion>
<InstallerBuildNumber>7</InstallerBuildNumber>
</PropertyGroup>
</Project>
main.proj
<Project ToolsVersion="4.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Import Project="importme.proj" />
<PropertyGroup>
<OutputName>asdf-$(InstallerMajorVersion).$(InstallerMinorVersion).$(InstallerBuildNumber)</OutputName>
<OutputType>Package</OutputType>
</PropertyGroup>
<Target Name="Build">
<Message Text="$(OutputName)"/>
</Target>
</Project>
OUTPUT
Microsoft (R) Build Engine version 4.0.30319.17626
[Microsoft .NET Framework, version 4.0.30319.17626]
Copyright (C) Microsoft Corporation. All rights reserved.
Build started 10.09.2012 12:35:12.
Project "d:\temp\SO\main.proj" on node 1 (default targets).
Build:
asdf-7.7.7
Done Building Project "d:\temp\SO\main.proj" (default targets).
Build succeeded.
0 Warning(s)
0 Error(s)
Time Elapsed 00:00:00.55
Run using
msbuild main.proj
UPDATE: You need to reload project for Include'd files to be updated or use workaround.
The reason it didn't work is that Visual Studio had cached the included file, so that any changes I made to it didn't take effect until I reloaded the solution or restarted Visual Studio. This seems to be a limitation of VS 2010. After reloading VS 2010, everything worked as expected.
The Import element is only valid under the Project element. However, the code appears to want to import the values into a <ProjectGroup> element. Try declaring the values as variables in Setup.Version.proj and reference them in your main MSBuild file, such as:
<Project ToolsVersion="4.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Import Project="../../Setup.Version.proj" /> <!-- Variables declared in here -->
<PropertyGroup>
<InstallerMajorVersion>$(MyInstallerMajorVersion)</InstallerMajorVersion>
<InstallerMinorVersion>$(MyInstallerMinorVersion)</InstallerMinorVersion>
<InstallerBuildNumber>$(MyInstallerBuildNumber)</InstallerBuildNumber>
<OutputName>asdf-$(InstallerMajorVersion).$(InstallerMinorVersion).$(InstallerBuildNumber)</OutputName>
<OutputType>Package</OutputType>

Can I use a property sheet to generate project configurations?

I'm trying to avoid hard coding settings into my .vcxproj files. I'd like to edit a single file, i.e. inherited property sheets (.props), to change my settings. This works great for compiler and linker settings. I also use this technique for all my dependent libraries like boost, zlib, for appending the include path and the libpath.
I'd like to take this a step farther and create the list of configurations in one property sheet.
Is this possible. I keep getting a error.
proj1.vcxproj
<?xml version="1.0" encoding="utf-8"?>
<Project DefaultTargets="Build" ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Import Project="configurations.props"/>
<PropertyGroup Label="Globals">
<ProjectGuid>{36327322-B9FA-4D71-1111-E94F5BB55D57}</ProjectGuid>
<RootNamespace>Proj1</RootNamespace>
</PropertyGroup>
<Import Project="$(VCTargetsPath)\Microsoft.Cpp.Default.props" />
<Import Project="$(VCTargetsPath)\Microsoft.Cpp.props" />
<Import Project="$(VCTargetsPath)\Microsoft.Cpp.targets" />
</Project>
configurations.props
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<ItemGroup Label="ProjectConfigurations">
<ProjectConfiguration Include="DebugUnicode|Win32">
<Configuration>DebugUnicode</Configuration>
<Platform>Win32</Platform>
</ProjectConfiguration>
</ItemGroup>
</Project>
proj1.vcxproj : error : Project "proj1" does not contain any
configuration. The project cannot be loaded.
So is this possible?
Sorry, that is a bug I reported in VS 2010 Beta 2, but a fix didn't make RTM.
Link to Connect bug report

Resources