project.json

.Net Core's project.json allows configuration of various assembly properties (e.g. title, version, copyright) that a traditional .Net application would define using attributes typically placed in AssemblyInfo.cs (e.g. AssemblyTitle , AssemblyCopyright , AssemblyVersion ). However, one assembly property I haven't figured out how to set in project.json is InternalsVisibleTo . Is there a way to use project.json to indicate that another assembly should have internal visibility into the current project? No - just put it in AssemblyInfo.cs as normal. That's still a perfectly fine place to put

I am currently working on a .NET Core library that I am going to use as a NuGet package in another project. I have been able to successfully package the project using the "dotnet pack" command in the project directory, and upload that package to MyGet. I would prefer to automate this process of pushing the NuGet package by using the "nuget push" command. My issue is that the "scripts" property defined in the project.json file does not seem to be executed on pack or build. I expected that these scripts would be executed when the corresponding event occurs, but they seem to have no effect as I

I have looked at the the ASP.Net 5 teams wiki entry for project.json , to identify which Script Commands are available, and currently the following are listed: { "scripts": { "prebuild": "echo before building", "postbuild": "echo after building", "prepack": "echo before packing", "postpack": "echo after packing", "prerestore": "echo before restoring packages", "postrestore": "echo after restoring packages" } } These are straightforward, and easy to understand; however in Visual Studio, only prerestore and postrestore events seem to actually fire. Prebuild and postbuild do not. The default

I followed the instruction to create new .NET Core project and ran this from cmd: dotnet new dotnet restore The second statement creates project.lock.json that contains a lot of garbage (not really garbage but tons of dependencies, configurations etc.). I assume these dependencies is .NET framework that is broken down into separate NuGet packages. My questions: Is my assumption correct? Can I make my application lighter by removing not needed NuGet packages/dependencies? How? Update : project.json has been replaced with .csproj as the main project file for .NET Standard projects. This question

I'm looking to convert my project to use project.json format, but still using the .NET CLR until 3rd party dependencies add support for CoreCLR. With that said, some of my NuGet dependencies of files in the "content" directory that need to be output into the bin directory of the running application. Since project.json currently doesn't support NuGet content, I manually added the files to my project directory. However, when I run the application, it still can't find these native assemblies. If I add these assemblies manually to .dnx\runtimes\dnx-clr-win-x86.1.0.0-rc1-final\bin , my application

I have a new ASP.net 5 dnx class library I am using for entity framework. I need to target EF 6 because some features I need are not in EF 7. First the EF tools (like enable-migration) were not there. I added an old style class library and installed EF 6 and now the commands are there. When I run enable migrations I get this error: PM> Enable-Migrations Exception calling "SetData" with "2" argument(s): "Type 'Microsoft.VisualStudio.ProjectSystem.VS.Implementation.Package.Automation.OAProject' in assembly 'Microsoft.VisualStudio.ProjectSystem.VS.Implementation, Version=14.1.0.0, Culture=neutral

I can't seem to find a way to make T4 templates in VS 2015 RTM, in an ASP.NET 5 (vNext) project. I even installed the T4 toolbox for Visual Studio 2015 extension, but the tt templates are not transformed. The property Custom Tool doesn't appear in the tt file properties, neither can't I find the ' Run Custom Tool ' command. Update The reason I want the T4 templates, is the introduction of the config.json file, and the pluggable configuration system, which is an awesome thing, but with the price of not having the setting properties strongly-typed. I've read this article that explains how to