We Keep Coding

FxCop Analysis with .Netcore library failed in VS2015 update 3

I was built my project(Class Library) in .Net core and trying to analyze my code using FxCop in VS2015.
But i am getting following error:
"could not identify platform for project"
Also i tried to set platform for my project. But i can't able to set it.
Any thing i missed here?
thanks,
Suresh

By referring this link Use code analysis with Visual Studio DNX project (.xproj)
I have added following lines in project.Json file now its working.
"frameworks": {
"net46": {
"buildOptions": {
"define": [ "CODE_ANALYSIS" ]
}
},
"netstandard1.6": {
"imports": "dnxcore50"
}
}
Note: After added the code in project.json file, close all visual studio application and start it. Then it will work.

Why does .Net Core CLI in VSCode put release folder in the debug directory

I feel like I'm missing something obvious, but searching google, this site and the .Net Core SLI issues section on GitHub did not immediately return an answer, nor did reading the documentation for the .Net Core project.json format.
In plain old C# projects (regular .Net, not Core) scaffolded by Visual Studio (not VSCode), usually running a build will put files in
%project root%/bin/Debug
out of the box, or
%project root%/bin/Release
if you choose publish.
In VSCode with .Net Core, by default build puts files in
%project root%/bin/Debug/netcoreapp1.0.
however if you run
dotnet publish
on the command line, it will put the files in a release folder inside
%project root%/bin/Debug/netcoreapp1.0.
resulting in a structure like
%project root%/bin/Debug/netcoreapp1.0/release.
If you have specified to build for a specific platform target in your project.json then it will similarly put the files in
%project root%/bin/Debug/netcoreapp1.0/PlatformName.
For example
%project root%/bin/Debug/netcoreapp1.0/win7-x64.
My question is, why does .Net Core put the release folder inside the debug folder and since I prefer the old directory structure, is there a way I can tell .Net Core to do it that way instead, say via some project.json property or cli flag similar to how say typescript allows you to specify an outDir?
Testing this with the default hello world project provided by 'dotnet new', my modified project.json looks like this:
{
"version": "1.0.0-*",
"buildOptions": {
"debugType": "portable",
"emitEntryPoint": true
},
"dependencies": {},
"frameworks": {
"netcoreapp1.0": {
"dependencies": {
"Microsoft.NETCore.App": {
//"type": "platform",
"version": "1.0.0"
}
},
"imports": "dnxcore50"
}
},
"runtimes": {
"win7-x64": { }
}
}

According to the documentation (bold is mine):
dotnet publish [--framework] [--runtime] [--build-base-path] [--output] [--version-suffix] [--configuration] []
...
-c, --configuration [Debug|Release]
Configuration to use when publishing. The default value is Debug.
So you need to use:
dotnet publish -c Release
(there's also the --output parameter to specify the destination folder: the documentation also states the default, which matches what you are seeing)

Why can't I use embedded resources (resx) when targeting .netstandard 1.3?

(Question subtitle: Are resources not supported in .netstandard 1.3 or is my project file just messed up?)
I just created an example portable class library in Visual Studio 2015 Update 3 and added a sample resource file. Initially, the file project.json looks like this:
{
"supports": {
"net46.app": {},
"uwp.10.0.app": {},
"dnxcore50.app": {}
},
"dependencies": {
"Microsoft.NETCore": "5.0.0",
"Microsoft.NETCore.Portable.Compatibility": "1.0.0"
},
"frameworks": {
"dotnet": {
"imports": "portable-net452+win81"
}
}
}
Fine: No compile errors!
After that, I used the project properties to target .NETStandard 1.3.
Now project.json looks like this:
{
"supports": {},
"dependencies": {
"Microsoft.NETCore.Portable.Compatibility": "1.0.1",
"NETStandard.Library": "1.6.0"
},
"frameworks": {
"netstandard1.3": {}
}
}
Now I get the following build error - which means basically the the build action EmbeddedRessource is not supported:
I'm really no expert with project.json, but for me the things look inconsistent - and I have no idea, where the problem is.
in the first project.json: if I support net46, why is it importing net452?
in the second project.json: if I use netstandard1.3, why is there a dependency to the library in version 1.6?
and finally, what is .NETPortable, Version=v5.0? The renaming of .NET Core has taken place early this year - why are we still referencing version 5.0? Even MSDN doesn't know <TargetFrameworkVersion>5.0</TargetFrameworkVersion> which is specified in the csproj
For me, this seems like netstandard isn't only about the available libraries, tooling seems involved, too. But that does not explain, why it worked for dnxcore50.

You need Diagnostics.Tools and Resources.ResourceManager.
I got this working (for .NET Standard 1.4 though) by installing the pre versions, at this time:
"System.Diagnostics.Tools": "4.3.0-preview1-24530-04"
"System.Resources.ResourceManager": "4.3.0-preview1-24530-04"

How can I use .Net Core Class Library (.NetStandard v1.5) into .Net Framework 4.6.2 Application

According to Mapping the .NET Platform Standard to platforms .NET Platform Standard 1.5 have to be compatible with .NET Framework 4.6.2. I have tried to use it (make new .NET Platform Standard class library, then new .Net Framework 4.6.2 console application), but the library is not recognized. What I am doing wrong?
project.json in class library:
{
"version": "1.0.0-*",
"dependencies": {
"NETStandard.Library": "1.5.0-rc2-24027"
},
"frameworks": {
"netstandard1.5": {
"imports": "dnxcore50",
"buildOptions": { "embed": "true" }
}
}
}

If you get the latest .net core RTM release and the Update 3 VS tooling, things are a little nicer than they were during the RC period. Still don't have easy project references from csproj referencing xproj - but, you can get things to talk by packing up the xproj output into a nuget package, then using the package manager to install that package. Also, you shouldn't need the imports on the framework, nor the dependency on netstandard.library, at least I don't. Here's how I've done it:
Create a .cmd file which will package the nuget files and two copy the output files to the folder where the package manager is expecting them. Here's that script, I call it makeNuget.cmd:
IF "%1" == "%2" (
dotnet pack --no-build --configuration %1 -o ../%3
xcopy %4 "...\%3\lib\%5\" /Y
)
Add a postbuild script in the project.json of the xproj to run the script
"scripts": {
"postcompile": [
"makeNuget.cmd %compile:Configuration% Release packages\%project:Name% %compile:OutputDir% %compile:TargetFramework%"
]
}
This should leave you with a nuget package in the packages\[projectName]\ folder at the root of your solution, with the binaries in the packages\[projectName]\lib\[targetFramwork]\ folder
Now, you need to add the packages folder as a package source, so first open the package manager console, then click the little gear to add a package source (or Ctrl+Q, package sources, Enter). Then click the add button, name this source, browse or type in the packages directory and hit ok.
In the package manager console, make sure both your package source and project are selected in the drop downs at the top.
install-package [your package name]
AFAIK, that's as good as it gets at the moment.

Do you really need .Net Framework 4.6.2 app?
I just created PCL (Portable class library) targeting .NETStandard1.4 and I can use it in WPF app which is targeting .NET Framework 4.6.1.
Here is how my project.json looks like in PCL project:
{
"supports": {},
"dependencies": {
"Microsoft.NETCore.Portable.Compatibility": "1.0.1",
"NETStandard.Library": "1.6.0"
},
"frameworks": {
"netstandard1.4": {}
}
}

ASP.NET 5 Web Application that references the new Class Library (package)

I am in the process of creating a large solution that contains an ASP.NET 5 MVC Web App which targets the following frameworks:
"frameworks": {
"dnx451": { },
"dnxcore50": { }
},
I have several of the new Class Library (package) in my solution for the business layer, data layer, etc.. All of these libraries target the following frameworks:
"frameworks": {
"net451": { },
"dotnet5.4": {
"dependencies": {
"Microsoft.CSharp": "4.0.1-beta-23516",
"System.Collections": "4.0.11-beta-23516",
"System.Linq": "4.0.1-beta-23516",
"System.Runtime": "4.0.21-beta-23516",
"System.Threading": "4.0.11-beta-23516"
}
}
}
I have a few test projects which target the following frameworks just like my MVC web app does:
"frameworks": {
"dnx451": { },
"dnxcore50": { }
},
After doing much research I mostly found that anything that is a project like my mvc app and test libraries should target dnx and projects that act as class libraries should just keep their defaults and target net/dotnet5.4.
Can someone please tell me what I am doing wrong because from my MVC Web Application I am unable to reference items from my class libraries (DAL, BLL) unless I add dnx451 to them...

You have "dnxcore50" in your Web application and "dotnet5.4" in your dll, which are probably different sets of referenced libraries. Either your Class Library should target "dnxcore50" or your Web App should target "dotnet5.4" with all it's dependencies

I just kind of resolved similar issue.
Actually, the issue is not the inability to reference your class libraries, but lack of support from Intellisense. You can manually reference your class library in project.json of your application and then use classes from your class library in your application. And application will build and run just fine. At lease mine did build and run. But VS will still highlight your classes form class library with red color and show "Cannot resolve symbol" warning message.
To add support of Intellisense I removed "dnxcore50" from project.json of application and added "net451". So, now I have the following project.json in application:
"frameworks": {
"net451": { },
"dnx451": { }
},
I cannot just reference only "net451" because I can't start the application then. DNX just exits with code 1. But with both "net451" for Intellisense support and "dnx451" for DNX support I'm able to continue work on my project and wait for proper solution in RC2 of ASP.NET Core.