We Keep Coding

Use local source code of NuGet package to debug and edit code

I have a solution with an application project (ASP.NET Core) and multiple library projects. I want to separate some of the library projects into a separate solution and turn them into NuGet packages.
With the libraries in the same solution I could of course simply edit something in a library, run the application and see how it works (and debug, if necessary).
However, when I turn the libraries into a NuGet package, the application references the packages from our private NuGet feed instead of the project file.
My question is: is it possible to locally "override" the package reference and use the local source code instead? That way I could still edit the libraries and see the effects in the application. This is a lot easier than having to publish a new package for every small change (especially when trying to fix an issue or implementing a new feature).

DNT (Dot Net Tools) does this. You can specify which packages to switch and where they are.
See the 'switch-to-packages' and 'switch-to-projects' command line switches.
Its a bit fiddley as (when I last tried) you had to create a config file that holds the mapping, and it seems to be easy to break the switching. But its something.
https://github.com/RicoSuter/DNT
I've not tried it, but maybe you can use it to switch to packages on a commit for the build server to work correctly? (Or to ensure the references are correct in source control?)

If you want to use nuget in your project and debug, even modify the source files of the nuget packages, this is not a good choice because you should build the nuget project(generate the new changed dll) and repack it as a nuget package, then reinstall, to enable the changes. It is too complex.
Once you install the nuget, no matter how many changes you make, it’s useless. The nuget installed at this time is the version you made before any changes. No matter how you change it, it is the previous version. The version stays at that timestamp, unless you repackage the project. Generate nupkg and update the nuget version.
So nuget is not a good choice for your situation, you should use ProjectReference.
Directly use the ProjectReference to reference two source projects, build at the same time, and get the changed parts at the same time.
ProjectReference could cross two different solutions.
Add this on the main project:
<ItemGroup>
<!--add any nuget project'csproj file like this to debug its source code-->
<ProjectReference Include="..\xxx\xxx.csproj">
</ProjectReference>
</ItemGroup>
If the proejct is out of the solution, you could directly use the full path of the nuget project's csproj to connect it.

I'm not sure what you mean by "override" but you can always add the library project to your ASP.NET Core solution and reference it like normal project references. A project referenced within a solution doesn't have to be physically placed in the same folder as the solution itself.
This, however, does require that any developer on the project has both GIT repositories cloned locally (given your two solutions are located in separate GIT repos) in order to be able to build the ASP.NET Core solution. But I don't really see that as a downside.

How to reference NuGet packages?

I'm a newcomer to .NET world, and at this point I'm super confused about the packages, references and how to reference them in my c# project.
I have 3 project in my solution:
DataAccess - which contains the logic for accessing data, the mapping between DTOs and entities, etc.,
DataAccessTest - contains unit tests for DataAccess project,
Service - wraps the DataAccess project into a Windows service.
Now, DataAccess project references AutoMapper (among others) to help with data transformation. It's included in <PackageReference /> element in the csproj file. It seems to be working fine when I'm doing dotnet restore, however dotnet build fails when trying to resolve the namespaces! The same goes for JetBrains Rider - it doesn't find the namespaces until I explicitly reference them in <Reference>!
Not sure if related, but the same goes for the dependent projects. For example, DataAccessTest references the DataAccess project - so that the test will run. However, it still requires adding the transitive dependencies (for example AutoMapper), on top of the project reference.
Is this the intended behavior? Do you need to keep both <PackageReference> and <Reference> for project to compile correctly?

In C# you Have to take care about referencing to other projects. if one project has been referenced to other project, the other project couldn't use or reference to first project. if you did, it will gives you compilation Error.

You need to install Nuget packages for each project that references methods in that package. So, if only your DataAccess project requires AutoMapper, it should be sufficient to add the Nuget package to that project. The solution is not much more than a wrapper around a bunch of projects. You should be able to publish a project separately. The project will take care of its own dependencies. It is hard to find out what goes wqrong. It may be helpful if you create a small testproject, e.g. create an empty console project and a DataAccess Library. Then you add a Nuget package to your DataAccess library and copile all stuff. In this way you can try to find out what is goning wrong. Make sure to install the Nuget Packages for the correct project (I got this wrong several times before I discovered how it really worked).

Referencing Library in ASP.NET Core 1.0 (vNext)

I am learning ASP.NET Core 1.0 (vNext). With that in mind, I have a solution that is structured like this:
MySolution
src
MyLibrary
MyClass.cs
project.json
MyWebSite
Startup.cs
project.json
I am successfully compiling MyLibrary from the command-line using dnu build. I ran dnu pack which generated MyLibrary.1.0.0.nupkg. There are also two folders: dnx451 and dnxcore50 which both contain MyLibrary.1.0.0.dll. I want to use MyLibrary in MyWebSite, however, I'm confused.
How do I "include" MyLibrary into MyWebSite? Do I manually copy over the .dll file? If so, which one? Should I use the nupkg file instead? This is a private assembly, I do not want to publish it globally via NuGet.
What do I put in MyWebSite/project.json to reference the MyLibrary assembly?

Are you using Visual Studio 2015 RC? If so then follow these steps:
Expand your web project in the Solution Explorer
Right click on References
Click on Add Reference... from the context menu
Select Projects from the Reference Manager
Tick the checkbox next to MyLibrary
Click OK
Profit
If you are not using visual studio then this can be achieved by updated the project.json file in your web project.
If you created a "vNext class library project" then add this to the dependencies property on the json object:
"dependencies": {
"MyLibrary": "1.0.0-*"
}

You don't have to publish the package to NuGet if you don't want to share it with other people/projects outside of your solution. You can just reference the package directly from source.
However, if that still doesn't work for you then you have three options:
Internalize using Roslyn. Example: project.json and the actual code
You can reference the sources directly. Example project.json
Create a build time dependency. Example project.json and actual code for the package

Several questions marked in bold.
(How do I "include" MyLibrary into MyWebSite?)
In MyWebSite/project.json: Add the reference like this (don't worry about the version number not showing up).
(Do I manually copy over the .dll file?)
No
(This is a private assembly, I do not want to publish it globally via NuGet.)
Then don't do that :)
Referencing your class library from your web application will make sure it is included when building the web application. Then you should copy your web application files to an application server able to run it. I think you should try to publish your web application to an Azure Web app and then use server explorer to look at what the files on the server looks like after publishing. Or did you already know there is no reason to make a package before using it in you web app?

Webtest - missing dll

When I creating webtests I want to add "Web Test Plug-in" I get message box with information that one of my nuget library is missing.
Whole my solution is compilable and this "missing" library exists as entry in csproj and config files. After compilation of test project this library is inside "bIn" folder. I check under dotPeek version, publicToken etc is correct.
My question is where webtest project look for this library?

If the webtests is missing a dependency:
Right click solution > manage nuget packages for solution > click manage on the package in question, then select your webtests project > ok.
If the webtests has a broken link to a dll :
Look at the references, and see if there are any yellow triangles, and where they point to. If that is the case, delete that reference and re-attach.

MSBuild .NET project that will output existing assembly as it's result

I need to create csproj file that will be usable as project reference in VS2013 and will output prebuilt binary as it's "Build" result.
We use referenced projects for build, however company policy doesn't allow access to some of that projects for everyone. As a result projects need to be updated manually to make them build. This is really a major inconvenience when switching branches and when making edits to project files, so I want to create dummy project that will be bound to pre-built binaries as their "output" and will be placed instead of real projects.
EDIT: Moving that assembly to Nuget package is not an option for now since Nuget has some issues with dev flow (when you need to debug/test/develop package). I saw some VS extension that implements switching between Nuget package and local project which might solve this issue, but I'm not sure if it will be accepted and want to explore other options.
To be clear - the thing I want to avoid is editing project in any way, so that project can be built cleanly after pulling it from Git, and I don't have to clean it every time before commit.

I haven't properly tested it, but the solution seems really simple (if I understand the question properly).
Just add this to the existing .csproj, overriding the Build target to just give the path to the pre-built assembly.
<Target
Name="Build"
Returns="$(TargetPath)" />
This assumes the TargetPath property already defined, and it should automatically be if you're modifying the original .csproj. Otherwise just define it yourself in a <PropertyGroup> before the Build task.
Note that having TargetPath defined is important for the ProjectReferences in your own project to resolve.

How about having those restricted (binary only) projects reside in an internal Nuget package feed, so that Nuget can install the packages as needed, on build?