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)
Related
I use some custom props file like this (my_super_props.props)
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<ImportGroup Label="PropertySheets" />
<PropertyGroup Label="UserMacros" />
<PropertyGroup>
<TargetOsName>linux</TargetOsName>
<RemoteGeneratedFilesDir>$(RemoteIntDir)generated_files/</RemoteGeneratedFilesDir>
</PropertyGroup>
<ItemGroup />
</Project>
VS generates vcxproj file for me like this (piece)
.....
<Import Project="$(VCTargetsPath)\Microsoft.Cpp.props" />
<ImportGroup Label="Shared" />
<ImportGroup Label="PropertySheets" Condition="'$(Configuration)|$(Platform)'=='debug|x86'">
<Import Project="my_super_props.props" />
</ImportGroup>
<PropertyGroup Label="UserMacros" />
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='debug|x86'">
<RemoteIntDir>$(RemoteProjectDir)/obj/$(PlatformTarget)/$(TargetOsName)/$(Configuration)/</RemoteIntDir>
</PropertyGroup>
.....
Inside Microsoft.Cpp.props - $(RemoteIntDir) already defined like this
<RemoteIntDir Condition="'$(RemoteIntDir)' == ''">$(RemoteProjectDir)/obj/$(Platform)/$(Configuration)/</RemoteIntDir>
So Inside my Targets i'ev got wrong value of $(RemoteGeneratedFilesDir)
for exmaple
my_proj/obj/x86/debug/generated_files
instead of
my_proj/obj/x86/linux/debug/generated_files
because properties expands at declaration time,
but i can't declare $(RemoteIntDir) earlier, cos it depends of $(TargetOsName)
So I must somehow reexpand $(RemoteGeneratedFilesDir) before targets start - but i don't know how ??
PS
$(RemoteIntDir) - filled with Visual Studio project configuraion UI Dialog, so i even can't change order of properties declaration/props imports and etc
Your requirements are in a mess and there are no default properties RemoteProjectDir,RemoteGeneratedFilesDir,RemoteIntDir on system Microsoft.Cpp.props file. So it is quite strange due to your description.
I have added
<RemoteIntDir Condition="'$(RemoteIntDir)' == ''">$(RemoteProjectDir)/obj/$(Platform)/$(Configuration)/</RemoteIntDir>
.....
into my Microsoft.Cpp.props file to keep the same MSBuild environment as yours.
I have two questions.
my_proj/obj/x86/linux/debug/generated_files, is your current build configuration is linux? And why did you have two similar configuration linux and debug under it?
Also, is it my_proj/obj/x86/linux/generated_files?
In this situation, I have trusted your description, and assume it is my_proj/obj/x86/linux/debug/generated_files.
Besides, the changed $(Configuration) will act on the whole msbuild files including Microsoft.Cpp.props system files and vcxproj file.
One
If your current build configuration is debug and Platform is x86, you should try to change your my_super_props.props file like this:
<RemoteGeneratedFilesDir>$(RemoteProjectDir)/obj/$(Platform)/$(TargetOsName)/$(Configuration)/generated_files/</RemoteGeneratedFilesDir>
Two
If your build configuration is linux(to create it, you have to enter Build top menu under VS IDE-->Configuration Manager-->click New under the Project Configuration then input linux under it)
First, you have to add these under your current vcxproj file:
<ImportGroup Label="PropertySheets" Condition="'$(Configuration)|$(Platform)'=='linux|x86'">
<Import Project="my_super_props.props" />
</ImportGroup>
<PropertyGroup Label="UserMacros" />
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='linux|x86'">
<RemoteIntDir>$(RemoteProjectDir)/obj/$(PlatformTarget)/$(TargetOsName)/debug/</RemoteIntDir>
</PropertyGroup>
Second, modify your my_super_props.props file:
<RemoteGeneratedFilesDir>$(RemoteProjectDir)/obj/$(Platform)/$(TargetOsName)/debug/generated_files/</RemoteGeneratedFilesDir>
Rebuild the project:
I have netcore 3.1 Console application with a Package Reference and a Project Reference.
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>netcoreapp3.1</TargetFramework>
<PackageId>MyPackageId</PackageId>
<Product>MyProduct</Product>
<GeneratePackageOnBuild>true</GeneratePackageOnBuild>
<AssemblyName>MyAssemblyName</AssemblyName>
<Version>1.0.1</Version>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Mono.Options" Version="6.6.0.161" />
</ItemGroup>
<ItemGroup>
<ProjectReference Include="..\..\src\MyUtilityProject.csproj" />
</ItemGroup>
</Project>
I would expect the pack function to reference the compiled dll's from MyUtilityProject, but instead it looks up the version from MyUtilityProject.csproj and converts it into a package reference.
Here is the generated .nuspec file:
<?xml version="1.0" encoding="utf-8"?>
<package xmlns="http://schemas.microsoft.com/packaging/2012/06/nuspec.xsd">
<metadata>
<id>MyPackageId</id>
<version>1.0.1</version>
<requireLicenseAcceptance>false</requireLicenseAcceptance>
<dependencies>
<group targetFramework=".NETCoreApp3.1">
<dependency id="MyUtilityProject" version="2.13.0" exclude="Build,Analyzers" />
<dependency id="Mono.Options" version="6.6.0.161" exclude="Build,Analyzers" />
</group>
</dependencies>
</metadata>
<files>
<file src=".\MyProduct\bin\Debug\netcoreapp3.1\MyProduct.runtimeconfig.json" target="lib\netcoreapp3.1\MyProduct.runtimeconfig.json" />
<file src=".\MyProduct\bin\Debug\netcoreapp3.1\MyProduct.dll" target="lib\netcoreapp3.1\MyProduct.dll" />
</files>
</package>
How do I convince the VS build job, that it should include the dll's and not reference the package?
The resolution to my problem was adding
<PackAsTool>true</PackAsTool>
to the project file.
I guess it was not quite clear from my question, that I was trying to build a tool, except for the fact that OutputType is exe.
This leads to the conclusion, that MicroSoft assumes that if you push a packet, all referenced projects are also pushed as packages.
I want to create a Visual Studio project that would allow me to see a bunch of JavaScript and other files and edit them as normal, but would also have a build step that can run any custom commands I want (currently some npm commands, possibly more later). Basically I want 3 features combined:
Be able to browse and edit files just like for any VS project (C#, C++, etc.)
Be able to run a custom build step by selecting "Build" in Visual Studio (including building the whole solution).
Be able to run that same custom build step from the command line (MSBuild).
Using a "shared project" (.shproj) allows me to easily see and edit the files, but there is no Build item in the context menu, even if I manually add a Build target:
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="15.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup Label="Globals">
<ProjectGuid>...</ProjectGuid>
</PropertyGroup>
<Import Project="$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.props" Condition="Exists('$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.props')" />
<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\CodeSharing\Microsoft.CodeSharing.Common.Default.props" />
<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\CodeSharing\Microsoft.CodeSharing.Common.props" />
<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\CodeSharing\Microsoft.CodeSharing.CSharp.targets" />
<Import Project="MyItems.projitems" Label="Shared" />
<PropertyGroup>
<Configuration>Debug</Configuration>
<Platform>Any CPU</Platform>
</PropertyGroup>
<Target Name="Build">
<Exec Command="ECHO My custom build!" />
</Target>
</Project>
I've also tried using a stripped-down VC++ project (since I don't actually want to run the C++ compiler) and this allows a build to be run from VS, but opening the project logs warnings like error MSB4057: The target "GetProjectDirectories" does not exist in the project. and trying to add files to fails with that error or similar ones.
There must be an easier way to do this!
From your current description, I think you want to create a js project in VS IDE.
However, VS IDE has the node js project template by default. And you should install the workload Node.js development under VS_Installer so that you can use it.
After that, you can create such project.
1) Adding js files or other files by right-click on the project-->Add-->Existing Item so that you can modify the files on VS IDE.
2) If you want to execute a custom build step that does not break the whole build, you should make the custom target depends on the default build.
You can use this:
<Target Name="CustomStep" AfterTargets="Build">
<Exec Command="ECHO My custom build!" />
</Target>
or
<Target Name="CustomStep" BeforeTargets="Build">
<Exec Command="ECHO My custom build!" />
</Target>
Note: If you use
<Target Name="Build">
<Exec Command="ECHO My custom build!" />
</Target>
It will overwrite the system build process and instead, run the command, which breaks the whole default build.
3) If you want to execute the custom build on msbuild command, you should specify the name of the custom target:
msbuild xxx\xxx.proj -t: CustomStep(the name of the custom target)
===============================================
Besides, if you still want to use C++ project template, you could create a empty c++ project which does not contain any clcompile files and then do the same steps.
If you do not want to use C++ compiler, you should only remove any xml node on the vcxproj file like these:
<ClCompile Include="xxx.cpp" />
<ClInclude Include="xxx.h" />
When you use the empty C++ project, you do not have to worry about that.
=========================================
Update 1
If you want to build this project on a build sever without VS IDE, I suggest you could install Build Tool for VS2019 which is an independent, lightweight build command line(It is equivalent to dotnet cli).
Build Tool for VS2019
Under All Downloads-->Tools for Visual Studio 2019--> Build Tools for Visual Studio 2019
Then, you have to install the related build workload such as Node.js Build tools and then we can use the command line to build node.js project on build sever.
The entire installation process is fast.
Inspired by Perry Qian-MSFT's answer, I managed to strip down a Node.js project to the bare minimum that I needed to get Visual Studio to load and build it, but without referencing any external files.
The main trick was VS needs a target named "CoreCompile" to be defined to show the Build menu item! (It also needs a "Build" target, but that one is more obvious.)
My project now looks like this:
<Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003" ToolsVersion="4.0">
<Import Project="$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.props" Condition="Exists('$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.props')" />
<PropertyGroup>
<Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
<SchemaVersion>2.0</SchemaVersion>
<ProjectGuid>(some guid)</ProjectGuid>
<ProjectHome>.</ProjectHome>
<ProjectTypeGuids>{3AF33F2E-1136-4D97-BBB7-1795711AC8B8};{9092AA53-FB77-4645-B42D-1CCCA6BD08BD}</ProjectTypeGuids>
</PropertyGroup>
<!-- These property groups can be empty, but need to be defined for VS -->
<PropertyGroup Condition=" '$(Configuration)' == 'Debug' ">
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)' == 'Release' ">
</PropertyGroup>
<Import Project="My.Build.targets" />
<!-- Define empty standard MSBuild targets, since this project doesn't have them. Doing it this way allows My.Build.targets to also be used in a project that does define them. -->
<Target Name="Build" />
<Target Name="ReBuild" />
<Target Name="Clean" />
<!-- NOTE: a target named "CoreCompile" is needed for VS to display the Build menu item. -->
<Target Name="CoreCompile" />
<!-- Files shown in Visual Studio - adding and removing these in the UI works as expected -->
<ItemGroup>
<Content Include="myfile..." />
</ItemGroup>
</Project>
And My.Build.targets looks like this:
<Project ToolsVersion="4.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Target Name="MyBuild" AfterTargets="Build">(build steps)</Target>
<Target Name="MyReBuild" AfterTargets="ReBuild">(re-build steps)</Target>
<Target Name="MyClean" AfterTargets="Clean">(clean steps)</Target>
<!-- This target is needed just to suppress "warning NU1503: Skipping restore for project '...'. The project file may be invalid or missing targets
required for restore." -->
<Target Name="_IsProjectRestoreSupported" Returns="#(_ValidProjectsForRestore)">
<ItemGroup>
<_ValidProjectsForRestore Include="$(MSBuildProjectFullPath)" />
</ItemGroup>
</Target>
</Project>
I have an ASP.NET MVC 5 project that I am trying to build on our company build server using MSBuild, however the build fails to restore NuGet packages. I am using Visual Studio 2015 and TFS.
My project structure is as follows:
Solution (.sln)
.nuget
NuGet.config
NuGet.targets
Project Folder
Project items (references, libraries etc)
Project.Test.Unit
Unit test items
Here is my NuGet.config file:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<solution>
<add key="disableSourceControlIntegration" value="true" />
</solution>
</configuration>
Here is my NuGet.targets file:
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<SolutionDir Condition="$(SolutionDir) == '' Or $(SolutionDir) == '*Undefined*'">$(MSBuildProjectDirectory)\..\</SolutionDir>
<!-- Enable the restore command to run before builds -->
<RestorePackages Condition=" '$(RestorePackages)' == '' ">true</RestorePackages>
<!-- Property that enables building a package from a project -->
<BuildPackage Condition=" '$(BuildPackage)' == '' ">false</BuildPackage>
<!-- Determines if package restore consent is required to restore packages -->
<RequireRestoreConsent Condition=" '$(RequireRestoreConsent)' != 'false' ">false</RequireRestoreConsent>
<!-- Download NuGet.exe if it does not already exist -->
<DownloadNuGetExe Condition=" '$(DownloadNuGetExe)' == '' ">false</DownloadNuGetExe>
</PropertyGroup>
<ItemGroup Condition=" '$(PackageSources)' == '' ">
<!-- Package sources used to restore packages. By default, registered sources under %APPDATA%\NuGet\NuGet.Config will be used -->
<!-- The official NuGet package source (https://www.nuget.org/api/v2/) will be excluded if package sources are specified and it does not appear in the list -->
<!--
<PackageSource Include="https://www.nuget.org/api/v2/" />
<PackageSource Include="https://my-nuget-source/nuget/" />
-->
<PackageSource Include="\\itliv-nas03\Development Team\NuGet\Packages" />
</ItemGroup>
<PropertyGroup Condition=" '$(OS)' == 'Windows_NT'">
<!-- Windows specific commands -->
<NuGetToolsPath>$([System.IO.Path]::Combine($(SolutionDir), ".nuget"))</NuGetToolsPath>
<PackagesConfig>$([System.IO.Path]::Combine($(ProjectDir), "packages.config"))</PackagesConfig>
</PropertyGroup>
<PropertyGroup Condition=" '$(OS)' != 'Windows_NT'">
<!-- We need to launch nuget.exe with the mono command if we're not on windows -->
<NuGetToolsPath>$(SolutionDir).nuget</NuGetToolsPath>
<PackagesConfig>packages.config</PackagesConfig>
</PropertyGroup>
<PropertyGroup>
<!-- NuGet command -->
<NuGetExePath Condition=" '$(NuGetExePath)' == '' ">\\itliv-nas03\Development Team\NuGet\NuGet.exe</NuGetExePath>
<PackageSources Condition=" $(PackageSources) == '' ">#(PackageSource)</PackageSources>
<NuGetCommand Condition=" '$(OS)' == 'Windows_NT'">"$(NuGetExePath)"</NuGetCommand>
<NuGetCommand Condition=" '$(OS)' != 'Windows_NT' ">mono --runtime=v4.0.30319 $(NuGetExePath)</NuGetCommand>
<PackageOutputDir Condition="$(PackageOutputDir) == ''">$(TargetDir.Trim('\\'))</PackageOutputDir>
<RequireConsentSwitch Condition=" $(RequireRestoreConsent) == 'true' ">-RequireConsent</RequireConsentSwitch>
<NonInteractiveSwitch Condition=" '$(VisualStudioVersion)' != '' AND '$(OS)' == 'Windows_NT' ">-NonInteractive</NonInteractiveSwitch>
<PaddedSolutionDir Condition=" '$(OS)' == 'Windows_NT'">"$(SolutionDir) "</PaddedSolutionDir>
<PaddedSolutionDir Condition=" '$(OS)' != 'Windows_NT' ">"$(SolutionDir)"</PaddedSolutionDir>
<!-- Commands -->
<RestoreCommand>$(NuGetCommand) install "$(PackagesConfig)" -source "$(PackageSources)" $(NonInteractiveSwitch) $(RequireConsentSwitch) -solutionDir $(PaddedSolutionDir)</RestoreCommand>
<BuildCommand>$(NuGetCommand) pack "$(ProjectPath)" -Properties "Configuration=$(Configuration);Platform=$(Platform)" $(NonInteractiveSwitch) -OutputDirectory "$(PackageOutputDir)" -symbols</BuildCommand>
<!-- We need to ensure packages are restored prior to assembly resolve -->
<BuildDependsOn Condition="$(RestorePackages) == 'true'">
RestorePackages;
$(BuildDependsOn);
</BuildDependsOn>
<!-- Make the build depend on restore packages -->
<BuildDependsOn Condition="$(BuildPackage) == 'true'">
$(BuildDependsOn);
BuildPackage;
</BuildDependsOn>
</PropertyGroup>
<Target Name="CheckPrerequisites">
<!-- Raise an error if we're unable to locate nuget.exe -->
<Error Condition="'$(DownloadNuGetExe)' != 'true' AND !Exists('$(NuGetExePath)')" Text="Unable to locate '$(NuGetExePath)'" />
<!--
Take advantage of MsBuild's build dependency tracking to make sure that we only ever download nuget.exe once.
This effectively acts as a lock that makes sure that the download operation will only happen once and all
parallel builds will have to wait for it to complete.
-->
<MsBuild Targets="_DownloadNuGet" Projects="$(MSBuildThisFileFullPath)" Properties="Configuration=NOT_IMPORTANT;DownloadNuGetExe=$(DownloadNuGetExe)" />
</Target>
<Target Name="_DownloadNuGet">
<DownloadNuGet OutputFilename="$(NuGetExePath)" Condition=" '$(DownloadNuGetExe)' == 'true' AND !Exists('$(NuGetExePath)')" />
</Target>
<Target Name="RestorePackages" DependsOnTargets="CheckPrerequisites">
<Exec Command="$(RestoreCommand)"
Condition="'$(OS)' != 'Windows_NT' And Exists('$(PackagesConfig)')" />
<Exec Command="$(RestoreCommand)"
LogStandardErrorAsError="true"
Condition="'$(OS)' == 'Windows_NT' And Exists('$(PackagesConfig)')" />
</Target>
<Target Name="BuildPackage" DependsOnTargets="CheckPrerequisites">
<Exec Command="$(BuildCommand)"
Condition=" '$(OS)' != 'Windows_NT' " />
<Exec Command="$(BuildCommand)"
LogStandardErrorAsError="true"
Condition=" '$(OS)' == 'Windows_NT' " />
</Target>
<UsingTask TaskName="DownloadNuGet" TaskFactory="CodeTaskFactory" AssemblyFile="$(MSBuildToolsPath)\Microsoft.Build.Tasks.v4.0.dll">
<ParameterGroup>
<OutputFilename ParameterType="System.String" Required="true" />
</ParameterGroup>
<Task>
<Reference Include="System.Core" />
<Using Namespace="System" />
<Using Namespace="System.IO" />
<Using Namespace="System.Net" />
<Using Namespace="Microsoft.Build.Framework" />
<Using Namespace="Microsoft.Build.Utilities" />
<Code Type="Fragment" Language="cs">
<![CDATA[
try {
OutputFilename = Path.GetFullPath(OutputFilename);
Log.LogMessage("Downloading latest version of NuGet.exe...");
WebClient webClient = new WebClient();
webClient.DownloadFile("https://www.nuget.org/nuget.exe", OutputFilename);
return true;
}
catch (Exception ex) {
Log.LogErrorFromException(ex);
return false;
}
]]>
</Code>
</Task>
</UsingTask>
</Project>
I have tried the following:
Added this code to the NuGet.config file:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<solution>
<add key="disableSourceControlIntegration" value="true" />
</solution>
<packageSources>
<add key="itliv" value="\\itliv-nas03\Development Team\NuGet\Packages" />
</packageSources>
<activePackageSource>
<add key="All" value="\\itliv-nas03\Development Team\NuGet\Packages" />
</activePackageSource>
</configuration>
Tried running through command line using:
nuget restore path\to\solution.sln which returns the following error:
WARNING: Unable to find version '3.4.1.9004' of package 'Antlr'.
C:\Users\it-chrism\.nuget\packages\: Package 'Antlr.3.4.1.9004' is not found on source 'C:\Users\it-chrism\.nuget\packages\'.
C:\Users\it-chrism\AppData\Local\NuGet\Cache: Package 'Antlr.3.4.1.9004' is not found on source 'C:\Users\it-chrism\AppData\Local\NuGet\Cache'.
I have tried editing my NuGet.targets file several different ways in hopes to fix (tried different package sources, different cases, removed/added quotation marks)
I have read the following documentation::
http://docs.nuget.org/ndocs/consume-packages/package-restore#migrating-to-automatic-restore but no success
I have updated to NuGet 3.3
Here is my error message when attempting to build:
Summary
Release | Any CPU
1 error(s), 0 warning(s)
$/Develop/Websites/VehicleLookupUI/VehicleLookupWebUI.sln - 1 error(s), 0 warning(s), View Log File
C:\Builds\1\Develop\VehicleLookupWeb-Develop\Sources\VehicleLookupUI\VehicleLookupWebUI\VehicleLookupWebUI.csproj (315): This project references NuGet package(s) that are missing on this computer. Use NuGet Package Restore to download them. For more information, see http://go.microsoft.com/fwlink/?LinkID=322105. The missing file is ..\packages\Microsoft.Net.Compilers.1.0.0\build\Microsoft.Net.Compilers.props.
$/Develop/Websites/VehicleLookupUI/VehicleLookupWebUI.sln compiled
No Test Results
No Code Coverage Results
Other Errors and Warnings
2 error(s), 0 warning(s)
Building the projects in this solution one at a time. To enable parallel build, please add the "/m" switch.
TF270015: 'MSBuild.exe' returned an unexpected exit code. Expected '0'; actual '1'.
I have a feeling that NuGet is looking in the wrong folder for the missing packages. I can include the sources in Tools > NuGet Package Manager.. > Package Manager Settings > NuGet Package Manager > Package Sources but this only works for me locally using Visual Studio and not using MSBuild attempting to build it 'out of the box'.
I am attempting to build on TSF by opening up Team Explorer > Builds, then right-clicking on my build and selecting Queue New Build...
You are using MSBuild-Integrated way to restore package, for this way, there is .nuget folder (contains nuget.exe, nuget.config and nuget.targets) in solution and need to be added to source control and you don’t need to add Nuget Restore build step/task to your build definition to restore package, so remove that step/task and set Clean to true in Repository tab of your build definition.
I recommended that you migrate to automatic restore:
Close Visual Studio to avoid file potential file locks and conflicts.
If using TFS: a. Remove nuget.exe and nuget.targets from the solution's .nuget folder and remove those files from the solution workspace. a. Retain nuget.config with the disableSourceControlIntegration setting as explained in Omitting packages with Team Foundation Version Control.
If not using TFS: a. Remove the .nuget folder from the solution and the solution workspace.
Edit each project file in the solution, remove the <RestorePackages> element, and remove any references to the nuget.targets file.
More information, you can refer to this article.
Please special Nuget.config file on TFS build server on the following location.
I am working with Visual Studio 2010. I have directed project output to a specific folder which will contain all the DLLs and EXEs when built. However when I clean the solution, the folder is not getting cleaned, and the DLLs are still present in it.
Can anyone tell me how to handle the clean solution command to clear out the folders I want to clean? I tried working with MSBuild and handling the BeforeClean and AfterClean targets, but it did not provide the desired result.
The answer from Sergio should work but I think it could be cleaner to override the BeforeClean/AfterClean targets. These are hooks into the build/clean process provided by microsoft. When you do a clean, VS do call the targets : BeforeClean;Clean;AfterClean and by default the first and the last do nothing.
In one of your existing .csproj file you can add the following :
<Target Name="BeforeClean">
<!-- DO YOUR STUFF HERE -->
</Target>
You can add to your VS .sln file special target named let's say BuildCustomAction.csproj:
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="3.5" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
<Platform Condition=" '$(Platform)' == '' ">AnyCPU</Platform>
</PropertyGroup>
<ItemGroup>
<CleanOutCatalogFiles Include="..\..\bin\$(Configuration)\**\*.dll">
<Visible>false</Visible>
</CleanOutCatalogFiles>
<CleanOutCatalogFiles Include="..\..\bin\$(Configuration)\**\*.exe">
<Visible>false</Visible>
</CleanOutCatalogFiles>
</ItemGroup>
<Target Name="Build">
</Target>
<Target Name="Rebuild"
DependsOnTargets="Clean;Build">
</Target>
<Target Name="Clean"
Condition="'#(CleanOutCatalogFiles)'!=''">
<Message Text="Cleaning Output Dlls and EXEs" Importance="high" />
<Delete Files="#(CleanOutCatalogFiles)" />
</Target>
</Project>
Place it everywhere you want and specify relative path to the output catalog for your binaries. Add in VS this project as existing. That's all. With this you can do own custom actions for three common actions in VS: Build, Rebuild, Clean.
There exists more complex way to customize build process using CustomBeforeMicrosoftCommonTargets and CustomAfterMicrosoftCommonTargets but it requires to be very good in MSBuild.
Hope this helps.