Cross-targeting frameworks with NuGet 4.0 and Visual Studio 2017 - visual-studio

I am having a rough time figuring out how to setup cross-targeting inside a Visual Studio 2017 project and I have not been able to find any examples.
I started out with a .NET Standard 1.5 project and to keep it simple I am just trying to add .NET Standard 1.6. If I understand the documentation correctly, I should now be able to do all of this inside the csproj file without having to mess with a project.json or nuspec file.
I've tried all of these values but none seem to work:
<TargetFrameworks>netstandard15;netstandard16</TargetFrameworks>
<TargetFrameworks>netstandard1.5;netstandard1.6</TargetFrameworks>
<TargetFrameworks>.NETStandard,Version=v1.5;.NETStandard,Version=v1.6</TargetFrameworks>
This is the only source of documentation I can find on the feature and it doesn't contain a full example:
https://docs.nuget.org/ndocs/schema/msbuild-targets
https://docs.nuget.org/ndocs/create-packages/supporting-multiple-target-frameworks

I've gotten this to work on latest Visual Studio 2017. As described in this post https://blogs.msdn.microsoft.com/dotnet/2016/10/19/net-core-tooling-in-visual-studio-15/ it is the correct way to do it. My csproj file looks like this:
<PropertyGroup>
<TargetFrameworks>netstandard1.6;net452</TargetFrameworks>
</PropertyGroup>
Visual Studio 2017 RC release notes also has this listed as a feature (under .NET Core and Docker):
Cross-target multiple target frameworks in one project.
My mistake at the start was that when I first created the project the property was called TargetFramework, I tried to add multiple targets and VS did not like that at all. It just crashes then... So make sure to rename it to TargetFrameworks and it should work.

Related

Unity keeps removing log4net from my Visual Studio project

I tried to install log4net for use in my Unity project with the following command :
Install-Package Unity.log4net
However, when I go back to the editor, then back to Visual Studio again, the log4net reference is removed, just like the Unity Editor had regenerated the project or something like that. The log4net reference no longer appears in the reference list and thus the log4net namespace can no longer be found.
I'm using Visual Studio 2017 Community Edition.
Has anyone experienced that and found a solution ? Thanks !
It seems like one cannot freely add references to a Unity project since Unity has to know about them. DLLs should be placed in a folder of the project called Plugins and then it works.
However it's weird that people are telling to use nuget packages. I'm assuming that must work somehow, but I don't know how. The solution above is dirty, but at least it works.
Unity projects require a special process to add NuGet packages. This is because when you open a project in Unity, its Visual Studio project files are regenerated, undoing necessary configurations. To add a package from NuGet to your Unity project you can check this doc from Microsoft: https://learn.microsoft.com/zh-cn/visualstudio/cross-platform/unity-scripting-upgrade?view=vs-2019

Prevent Visual Studio from trying to parse typescript

Working on a project using Visual Studio as my IDE. It has an API component written in C#, and a webserver component that uses TypeScript.
I am using webpack to deal with the typescript compilation and would like to remove the Visual Studio build step from the typescript files.
Normally I wouldn't care if it was building them, but I am using Typescript > 1.8.4 which has language features that Visual Studio cannot understand which is making Visual Studio throw errors and prevent compilation. I found a workaround for this in this github issue thread but I have other developers cross team who are working on this and trying to coordinate a hack to make code among them will not work.
I have also tried removing the typescript imports line from the .csproj file, but whenever I add a new ts file, it adds the line back in.
Is there a way to completely shut down the typescript compilation/parsing step in Visual Studio and prevent it from coming back?
This in in VS 2015.
You can disable typescript compilation by editing the .csproj file to contain the following:
<TypeScriptCompileBlocked>true</TypeScriptCompileBlocked>
That should disable all typescript compilation within VS 2015.
To disable TypeScript compilation altogether for Visual Studio, edit:
C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\Microsoft\VisualStudio\v15.0\TypeScript\Microsoft.TypeScript.targets
(Your path might be slightly different depending on your OS/VS version, in that case just search for Microsoft.TypeScript.targets)
And add:
<PropertyGroup>
<TypeScriptCompileBlocked>True</TypeScriptCompileBlocked>
</PropertyGroup>
This works for .NET Core projects as well.
It seems that the errors are triggered by IntelliSense and one can remove IntelliSense errors by simply filtering the list.
In case that other solutions doesn't help this is the key to clean up the error list, at least temporarily.
Sam Storie's answer is a great start and it will stop typescript errors from preventing compilation, but Visual Studio will still report the parsing errors which will prevent the ability to use the built in publishing tools.
To completely remove error reporting in ts, find all import lines in the csproj that reference typescript and set the Condition property to false, make sure to restart VS afterwards:
Example:
<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\TypeScript\Microsoft.TypeScript.targets" Condition="false" />
Remove / Uncheck Test Javascript Content Files from the Project filter.

Convert SharePoint 2010 Solution to 2013 and Visual Studio 2012

I am trying to convert a SharePoint 2010 solution (custom web parts, content types, lists, event receivers, etc.) developed in Visual Studio 2010 to SharePoint 2013 and Visual Studio 2012. When I open the project in VS 2012, it converts a couple of the project files but won't compile because of reference issues.
I copied the DLLs (mostly Microsoft.SharePoint..., although I needed to copy the Microsoft.Office.SecureStoreService.dll too) that were causing issues from my 2010 server to the 2013 server and fixed the references. However, the Microsoft.Office.SecureStoreService.dll still gives me compiler errors claiming "Error 203 The type or namespace name 'Office' does not exist in the namespace 'Microsoft' (are you missing an assembly reference?)" when visual studio has no problem with the namespace and finds the SecureStoreProvider class inside it just fine.
I've also tried to change the target framework from 3.5 to 4 and only see "Install other frameworks..." in the target framework dropdown.
I'm sure that others have dealt with this, but have been unsuccessful in framing the right google search query. I'm relatively new to SharePoint in general and any help would be appreciated.
thanks,
Mike
I was able to get my solution upgraded from a 2010 project to 2013 using the following. Note that this will update your solution to use the new 2013 API. It is possible to update just the project file but still run in 2010 mode.
First edit your .csproj file (for c#).
Modify the target framework to this:
<TargetFrameworkVersion>v4.5</TargetFrameworkVersion>
Add this a node for the office version, I put mine directly below the TargetFrameworkVersion tag
<TargetOfficeVersion>15.0</TargetOfficeVersion>
Update references
Reload the project and update your referenced assemblies. If you haven't specified a specific version they should already be referencing the v15 (SharePoint 2013) assemblies.
Do a find replace for 14.0.0.0 to 15.0.0.0. This updates any references on your pages, layouts, and master pages to the v15 assemblies.
Change calls
Change any calls to SPUtility.GetGenericSetupPath() to SPUtility.GetVersionedGenericSetupPath()
Check each file to do a check for any hive references. You'll need to add a /15/ to these. EG: _layouts/ to _layouts/15/
Open the package "folder" in visual studio then update the properties for that package to use version 15.
Clean up
Finally do a compile clean up any missed items. Deploy your solution and make sure to test thoroughly.

Projects dependencies between C# and C++ project, build order

If both project Alpha and project Beta are C# projects, we can set that Beta depends on Alpha and this results to following build order: 1) Alpha; 2) Beta
If project Alpha is C++ project, we cannot add reference from project Alpha to Beta because Visual Studio 2010 does not allow this. Actually we can hack csproj file with notepad, but it doesn't help. Bu we can right click on solution, choose Project Dependencies and say that Beta depends on Alpha.
Problem: MSBuild does not honor dependencies set in sln file and builds projects in wrong order - 1) Beta; 2) Alpha. Note, that Visual Studio honors build order.
How we can set build order for MSBuild between C# and C++ projects within same solution?
Try adding your C++ project reference to the C# project after cleaning the solution. This works for me, although I stumbled on this "workaround" by pure chance.
To me it looks as if Visual Studio is checking the build product of the referenced project, and when it notices the incompatibility it will refuse to add the reference. If, however, the build product is not around to check (because you cleaned the solution), Visual Studio happily adds the reference.
I tested the resulting solution both in Visual Studio and on our TFS build server (which AFAIK uses MSBuild) and build dependencies were evaluated correctly in both cases.
In your question you also mention that manually editing the .csproj file didn't help. I cannot confirm this. I was able to add the following reference and again got a positive build result:
<ProjectReference Include="..\Foo\Foo.vcxproj">
<Name>Foo</Name>
<ReferenceOutputAssembly>false</ReferenceOutputAssembly>
<Private>False</Private>
</ProjectReference>
I am adding the ReferenceOutputAssembly element because this blogs.msdn.com article suggests it. In my experience, though, the build also works without the element. The article is still worth reading because it explains why MSBuild does not honor dependencies defined in the solution.
For completeness sake: I am running Visual Studio 2010, Version 10.0.40219.1 SP1Rel.

Creating a custom project type for Visual Studio to build Borland C++ Builder projects into Visual Studio

I want to start the develop of a custom project type for Visual Studio that builds a BPR project with Visual Studio.
I need some hints to beginning with this project. Where can I find a template for this type of projects?
My target is to remove the Borland C++Builder's ugly and unstable interface from the development process and work enterely from Visual Studio.
Edit: Oops, I didn't really see that you're about to create a new project type for C++ Builder files. In that case, you have to build a language package. The Visual Studio Extensibility site should get you started. Also have a look at this more specific link.
I'll leave my old answer here for reference, because it might help people who just want to build C++Builder projects without creating a whole new project type :)
You didn't specify the version of Visual Studio, but I'll assume a recent one. In Visual Studio 8 and 9, most project files (all popular ones except Visual C++) are actually MSBuild files and can therefore be built by MSBuild. You can add a simple command line task (Exec) to build your bpr on the command line, or you can create a custom task for this (if you don't find one already available - the search terms should be MSBuild and custom task). This way, both Visual Studio and MSBuild can build anything you like. If you don't have an MSBuild file to start with or want to dive into developing a task, the MSBuild project template for Visual Studio will help you.
Oh, and other than that, if you don't actually need C++Builder things, you might as well export the BPR as a solution (or create a new solution and add the files).
Integrating C++Builder projects into a build process should be a lot easier with C++Builder 2007 or 2009 as both use MSBuild as build system. But then, I think that upgrading to a recent version of C++Builder solves your problem the other way :)

Resources