I want to package some tools as a nuget and am using the Microsoft.Build.NoTargets project SDK format to achieve the same.
As mentioned in the docs, NoTargets is used when the project file does not compile any assembly. However, it needs a TargetFramework property to be set.
msbuild fails with NETSDK1013 if I don't specify some TargetFramework property.
Why does msbuild mandate that TargetFramework be specified for the NoTargets SDK csproj?
Currently this is required for it to load in VS: VS checks if the project contains TargetFramework or TargetFrameworks in the xml to load sdk-based projects in the "new" project system (the thing that powers the IDE integration of the project). Otherwise it would use the legacy system that would not understand the features the SDK uses and either not load or give you a bad experience.
The MSBuild errors could be fixed in the SDK by defaulting the property but that will still fail IDE integrations.
Also note that the SDK imports other SDKs that are meant for .NET projects (language-independent over F#/C#/VB) and so you should get features like NuGet restore or packing working without much friction when a TargetFramework is set (even if it could be defaulted to whatever the SDK is basdded on in the NoTargets itself as mentioned)
Related
I am taking the plunge and am converting a (Profile 7) PCL to the new .NET Standard format. I mostly have everything working. (This is a great article -- but perhaps a little dated -- if you are interested).
My only remaining issue is that it doesn't appear that the .targets file for one of my dependencies (PostSharp) is executing during the build of my project. I have been looking all over to see how to include/execute a MSBuild .targets file.
The closest I could find is some sort of spec listing here:
https://github.com/NuGet/Home/wiki/%5BSpec%5D-Managing-dependency-package-assets
However, that doesn't appear to be available when I break out my dependency node. The only available options are "build" and "default":
So, is it possible to include/execute an MSBuild .targets file manually in a project.json file?
OK this was due (as to most of my problems!) to poor understanding of the new paradigm as I learn it. It turns out you can reference .NET Standard libraries from a PCL that is running project.json. The trick is to NOT upgrade the PCL to .NET Standard, and simply update it to use project.json (and NuGet 3.0), using the same profile that was used pre-project.json.
From there you can reference any .NET Standard library and/or any traditional/legacy PCL from the new project.json-PCL. Kind of cool. :)
I just upgraded my TFS source to use DevExpress 15.2.5. However, now I get a bunch of warnings in the output such as
C:\Program Files (x86)\MSBuild\14.0\bin\Microsoft.Common.CurrentVersion.targets(1819,5): warning MSB3274: The primary reference "C:\Users\User1\Source\Release\V6.1\CommonBin\Release\WebControls.dll" could not be resolved because it was built against the ".NETFramework,Version=v4.5" framework. This is a higher version than the currently targeted framework ".NETFramework,Version=v3.5".
and
C:\Program Files (x86)\MSBuild\14.0\bin\Microsoft.Common.CurrentVersion.targets(1819,5): warning MSB3275: The primary reference "C:\Users\User1\Source\Release\V6.1\CommonBin\Release\WebControls.dll" could not be resolved because it has an indirect dependency on the assembly "DevExpress.Data.v15.2, Version=15.2.5.0, Culture=neutral, PublicKeyToken=7ea533hgx2169hs3" which was built against the ".NETFramework,Version=v4.0,Profile=Client" framework. This is a higher version than the currently targeted framework ".NETFramework,Version=v3.5".
along with about 30 other similar warnings.
It's obvious that something is out of sync with my assemblies because they are referencing the wrong versions. So I looked at my TFS project .csproj file. The version of DevExpress and .NET framework that are being referenced in there are correct.
I then went to the Microsoft.Common.targets file and opened in Notepad. I noticed that file is referencing the old version of everything. How do I get this in sync with my TFS assemblies?
It looks like you need to change your project to use the .NET framework version 4.5 on the project properties page:
Word of warning this may result in more warnings or errors depending on the .NET APIs you use.
I'm trying to configure Visual Studio Online to continuously deploy my ASPNET 5 application to an Azure webapp as described in this tutorial from the Team Foundation Build docs: https://msdn.microsoft.com/Library/vs/alm/Build/azure/deploy-aspnet5
I have followed all the steps and everything is working great. By default this script deploys a build of my app that targets the full .Net 4.5.1 DNX so I decided to try and modify it to deploy for .Net Core.
The build script creates its deployment package by calling: msbuild.exe /t:Build,FileSystemPublish
After turning up log verbosity and reading through the relevant msbuild files I have learned the following:
The "Build" target ultimately uses dnx.exe to compile the project. Because the project.json file includes both dnx451 and coreclr TFMs this step produces build output for both frameworks - so far so good.
However, the FileSystemPublish target seems to only output an msdeploy package that targets the .Net 4.5.1 runtime. From the logs I could see executing the FileSystemPublish target ultimately issues a "dnu publish" command and in my cases passes "dnx-clr-win-x86.1.0.0-beta6" as the -runtime parameter. When I followed the breadcrumbs to find out where it was getting the value "dnx-clr-win-x86.1.0.0-beta6" from I eventually ended up in the "GetRuntimeToolingPath" task in Microsoft.DNX.Tasks.dll. This task seems to look in global.json to determine the correct runtime to use but strangely appears to internally override this value with "x86" and "clr" before creating the return string.
If I have interpreted things correctly, it seems that the FileSystemPublish target (in Microsoft.DNX.Publishing.targets) is essentially (indirectly) hard wired to use the x86, full .Net framework DNX when it produces its package output. At this point I am stuck for how to get this build process to produce a .Net Core package.
My question is why would FileSystemPublish be coupled to the x86 full .Net DNX and given this appears to be the case (unless I am mistaken) what is the recommended way to produce an msdeploy package for an ASPNET 5 app that targets .Net core?
EDIT:
For now I have a workaround. I can pass /p:RuntimeToolingDirectory="C:\Users\buildguest\.dnx\runtimes\dnx-coreclr-win-x64.1.0.0-beta6" as a parameter to msbuild.
This overrides the default logic in the GetRuntimeToolPath and forces it to use .Net Core. This works but feels like a hack so I'm leaving the question open for a better answer.
To publish Core CLR, you can pass the msbuild parameter 'PublishDNXVersion' as dnx-coreclr-win-x64.1.0.0-beta6.
msbuild <project>.xproj /p:deployOnBuild=true;PublishDNXVersion=dnx-coreclr-win-x64.1.0.0-beta6
From the Old Azure portal within the Web App section of it on the Dashboard page of your particular Web App.
[deep breath]
On the right hand side is a section that says "set up publishing with visual studio online". Clicking on that link will walk you through the necessary steps to set up continuous deployment from a visual studio online repository (either git or tfs based)
Since that is a mouthful, I have provided a link to a tutorial which walks you through the entire process: https://azure.microsoft.com/en-us/documentation/articles/cloud-services-continuous-delivery-use-vso/#step3
Had the same problem with .NET Core RC2-preview1 tooling. My solution: Add SDKToolingDirectory to my .xproj with a proper path to .NET Core installation:
<PropertyGroup>
<VisualStudioVersion Condition="'$(VisualStudioVersion)' == ''">14.0</VisualStudioVersion>
<VSToolsPath Condition="'$(VSToolsPath)' == ''">$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)</VSToolsPath>
<SDKToolingDirectory>C:\Program Files\dotnet</SDKToolingDirectory>
</PropertyGroup>
I had some luck with this by passing the following parameters into the Bundling step of my Visual Studio Online build process:
/p:Bundle64BitRuntime=true /p:BundleCoreClrRuntime=true
This causes my publish to leverage the 64 bit CoreCLR Runtime when it runs through msbuild.exe.
I figured this stuff out by digging through the Microsoft.DNX.Publishing.targets file (found at C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\Web) and looking for variables I could pass in as properties. Regarding runtime, this seems to be an interesting snippet:
<GetRuntimeVersion
Condition="'$(IgnoreDNXRuntime)' != 'true'"
RuntimeVersionOverride="$(PublishDNXVersion)"
TargetDNXVersion="$(_DefaultDNXVersion)"
RuntimeToolingVersion="$(RuntimeToolingVersion)"
Want64Bit="$(Bundle64BitRuntime)"
WantCoreClr="$(BundleCoreClrRuntime)">
<Output PropertyName="FinalPublishVersion" TaskParameter="RuntimeVersion"></Output>
</GetRuntimeVersion>
There's probably a little bit(?) of risk here in terms of future proofing your build routine against future changes to variables names. But, you know, beta software and all that :)
Good luck!
Please bear with me on this, since I am a Java developer just dipping a toe into the ASP.Net world
I started coding in an existing C# VS2012 codebase. It uses nuget and Newtonsoft is mentioned in the packages.config
When I right-click on Controllers > Add a new controller, I get the following error.
Could not load file or assembly 'nunit.framework, Version=2.2.4.0, Culture=neutral, PublicKeyToken=...' or one of its dependencies.
The system cannot find the file specified.
Now looking around in Google, it seems the GAC is missing an NUnit assembly. Not sure what I should do about that. Should I get NUnit? Why is it looking for a certain version of nunit (& that too a very old one)?
Any help for me to resolve this problem will be highly appreciated!
When you click "Add new Controller' Visual Studio will try to complete the parse/build to populate a number of values in the window that it is supposed to show you (with the available Models and available Views). It looks like at least one of your projects is missing a dependency (probably your Unit Test project).
NUnit 2.2.4.0 is indeed a pretty old version, it doesn't even exist on NuGet yet (which would have been an easy fix). It makes sense that NUnit is not installed in the GAC, since you normally don't put everything in the GAC just because it seems to be possible. If you're willing to upgrade to the latest NUnit version, the easiest way is to add the NUnit NuGet package to your project through the Package Manager.
I would assume that when you'd open the project file for the project that is generating this warning in Notepad, you'd see a <hintpath> tag as a sibling of the NUnit Reference (it may not be there) which points to the folder where it is telling Visual Studio to look for NUnit.
I suggest you install the NUnit version your project is looking for from here and then update the reference in your project to point to the correct location. That should fix the issue.
As for your remark on the specific version, .NET Assemblies are compiled with a specific version number (usually set in the AssemblyInfo.cs) a reference in a project file can be to a specific version or to any assembly with that name (highlight the reference in the Solution Explorer and check the properties window (ctrl+w,p or alt+enter). You'll see a property "Specific Version" which in your case is set to "true" which caused Visual Studio to store the assembly version in the project file.
Add the code files into a workable solution project.
It is workable for me.
Or, try to create a new Nunit test project with the codes
I also try the following method, but not working for me
Install Nunit, adapter, SDK from the Nuget package
Clean-Rebuild
For Noda Time version 1.1, the main goal is to build a Portable Class Library flavour, primarily to support Windows Phone and Windows Store apps. This means losing some functionality, so we build a desktop configuration and a PCL configuration (for each of debug, release, and "signed release").
To avoid having to work with umpteen project files, all of the 6 configurations exist in the same project file. The project file is customized to generate a property called "Portability", which is set to either "PCL" or "Desktop", like this:
<!-- Set the custom Portability property based on configuration -->
<PropertyGroup>
<Portability Condition="'$(Configuration)' == 'Debug Portable'">PCL</Portability>
<Portability Condition="'$(Configuration)' == 'Release Portable'">PCL</Portability>
<Portability Condition="'$(Configuration)' == 'Signed Release Portable'">PCL</Portability>
<!-- Default to desktop if not explicitly set above -->
<Portability Condition="'$(Portability)' == ''">Desktop</Portability>
</PropertyGroup>
We then have separate property groups for portable vs desktop, based on the above property. This is what defines the project type as "class library" or "portable class library" (along with the OutputType of Library, which is shared):
<!-- Desktop-specific properties -->
<PropertyGroup Condition="'$(Portability)' == 'Desktop'">
<TargetFrameworkVersion>v3.5</TargetFrameworkVersion>
<TargetFrameworkProfile>Client</TargetFrameworkProfile>
</PropertyGroup>
<!-- PCL-specific properties -->
<PropertyGroup Condition="'$(Portability)' == 'PCL'">
<MinimumVisualStudioVersion>10.0</MinimumVisualStudioVersion>
<ProjectGuid>{c78f6992-28d7-45c9-a4c1-6eaa649f3247}</ProjectGuid>
<TargetFrameworkVersion>v4.0</TargetFrameworkVersion>
<TargetFrameworkProfile>Profile2</TargetFrameworkProfile>
<ProjectTypeGuids>{786C830F-07A1-408B-BD7F-6EE04809D6DB};{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}</ProjectTypeGuids>
</PropertyGroup>
This generally works very well - I have the different solution configurations, so I can build and test everything at a moment's notice, and I only need to add each new .cs file to a single project file. So under Visual Studio 2012 Professional (which is what I use) I'm perfectly happy.
The problem comes when I try to load the solution in Visual Studio Express (either VS2010 or VS2012). While the solution is loading, it fails with an error to say that some projects can't be loaded, and the two projects which build PCL versions then have build output like this:
C:\Path\To\NodaTime.csproj : error :
The project file 'C:\Path\To\NodaTime.csproj' cannot be opened.
There is a missing project subtype.
Subtype: '{786C830F-07A1-408B-BD7F-6EE04809D6DB}'
is unsupported by this installation.
(Reformatted for clarity.) The two projects refuse to load, so you can't even browse the source code.
I had really hoped that even if Express users couldn't build the PCL versions, they'd still be able to load up the solution, browse the source, and build non-PCL versions. MSBuild works from the command line, but that's not as friendly.
I've tried removing the solution configurations which refer to the PCL project configurations, and that doesn't help. Weirdly enough, even commenting out the XML element, like this:
<!--
<ProjectTypeGuids>(Guids as before)</ProjectTypeGuids>
-->
doesn't help - although deleting the line does. It's as if Visual Studio isn't actually loading it as a real XML file. (I haven't tried loading the version with the commented out element into VS Pro.)
I could go down the route of generating separate PCL project files if I need to, but I'd really like to avoid it if possible - it would make normal development more painful. Likewise I could generate Express-only PCL and solution files, but again I'd rather not - it just feels wrong.
While ideally I'd like to support VS Express both 2010 and 2012, if there's a solution which only works for 2012, that would be a good start.
So, is there any way of persuading Visual Studio Express that it really can load a project despite a conditional property group (whose condition isn't met) referring to a project type it doesn't know about?
David Kean's comment here gave me the answer I'm using for the moment:
or remove the <ProjectTypeGuid> element entirely - this will opt you of "portable" enhancements, such as a UI for changing the target framework, etc
I've tried that, and it works like a dream. On machines which have everything appropriately installed, you can then even build the PCL version under Express! I've verified that the resulting binary really is a PCL, and it seems fine.
I wouldn't be surprised to find that I ran into some problems later on, but for the moment this works fine for me. I can easily live without the enhancements in Visual Studio - it was already confused by my project having very different build configurations, so I don't think I was getting much benefit anyway.
As answered here:
Visual Studio 2012 Express with Portable Class Library?
and here:
Share functionality using Portable Class Libraries
Portable Class library projects are not supported in the express
SKU...need a higher SKU for the full support. Of course the binary
(e.g., using it as a reference) is, just not the project/source
support.
I can imagine there is a simple reason for that - there are different types of VS2012 Express editions: for Windows Phone development, for Desktop apps, for Windows 8 apps... I bet the Windows Phone Express edition does not know about the Windows Phone project type and vice versa. This could be the simple reason why PCLs are not supported as well.
Although the idea of Portable Class Libraries is really nice, it's still quite limited in many ways, for instance you cannot use conditional compilation using #if xy as far as I know. If you really have to use Visual Studio Express for development, then it might be better to use projects for each platform with referenced source files and conditional compilation.