We Keep Coding

Nuget Package both source and dlls

I want to create a .Net class library and allow the users the option to either use the DLL or the C# source directly.
I know how to pack DLLs. I know how to pack source only packages (although it doesn't work for SDK style libraries). But I don't know how to allow the users to chose one.
This question has no answers and suggests that setting a default value for <IncludeAssets> is not possible. So by default both will be included and might cause conflict ?
This SO answer suggests to create two multiple NuGet packages like Foo and Foo.Sources. But I don't know how to do that in a neat workflow for a single solution/project either.
Any suggestions/resources or even example packages would be helpful.

Nuget Dependencies in .NET Core

If I install some Nuget package Package1, it is added to Dependencies/Packages/Package1. When I install another Nuget package Package2 which has dependency to Package1, there will be added Dependencies/Packages/Package2/Package1.
In this case I have right now this:
Dependencies
|_Packages
|_Package1
|_Package2
|_Package1
There is duplicity of the Package1. Should I remove the Dependencies/Packages/Packages1, or is it ok like this? Isn't it takes more space?

It's fine, assuming both your direct dependency and the indirect one use the same major version. If they have different major versions, you could be in trouble, as they may well be incompatible. (This is a weakness in .NET versioning at the moment, IMO.)
You can remove the direct dependency if you want - unless you want a later version than Package2 depends on. For example, if Package2 depends on Package1 version 1.2.0, but you want something that's only in Package1 version 1.5.0, it's fine for you to state that dependency explicitly. Only one version of Package1 will end up being deployed.

This user-interface feature isn't showing you files on disk. It's a logical hierarchy of dependencies and Nuget doesn't store downloaded packages like this physically. You can't "remove" them because the UI is showing you a statement of fact - this package does depend on these other packages.
(It took me a while to understand what you were asking because I was looking for this structure on disk, and could not reproduce this.)

If Package2/Package1 contains everything Package1 contains by itself, you won't need to reference it twice.

ASP.NET 5 Dependency Resolution

I'm trying to tinker arround with ASP.NET5 and all the new Magic we get.
I created a small Application, which receives a MAC-Address and sends a WakeOnLan-Package. For the abstraction of the WoL, I tried to use the SharpPCap-Library: http://www.codeproject.com/Articles/12458/SharpPcap-A-Packet-Capture-Framework-for-NET
I can add the References and even set the Object, but it seems only be avaliable on 4.5. Simply put, do need Asemblies be compatible to DNX 4.5.1 AND DNX Core 5.0?
I tried to add the Automapper, which works, but this one is shown on both Reference-Folders DNX 4.5.1 and 5.0. Does this mean, this Assembly is kindahow working on both Versions? If yes so, how is this possible, if other Assemblies don't seem to be compatible?
My 3. question raises from the Project-References: I added the Model-Project to my WebGui one, but Intellisense keeps marking the Model-Objects red and telling me, he can't resolve it. Funnily enough, building and Runtime work perfectly fine. Is this an issue of the Compiler atm?
If you have any resources on the general topic, I would be glad as well. I found some threads about this theme, like Jon Skeets problem: How can I diagnose missing dependencies (or other loader failures) in dnx? or the diagnosing: http://davidfowl.com/diagnosing-dependency-issues-with-asp-net-5/ but I guess, my problem is on a more basic level.
Thanks in advance.

You don't need DNX Core 5.0 - that's all the .NET Core stuff which SharpPCap probably isn't compatible with. If you can, just get rid of that framework like this in your project.json file:
"frameworks": {
"dnx451": {
}
},
It's probably the same thing for your Model-Project. getting rid of dnxcore50 should help. Basically by doing that you are saying your project needs full .NET, so it might not be as easy to run it on Linux etc...

The red line issue might be a re-sharper problem if you're running that?
see: Dnx 4.5.1/Dnx Core 5.0 Ambiguous reference

How do you configure C# projects to build using Windows SDK 7.1 tools?

We're trying to switch a lot of projects over to use SDK7.1. This seems pretty straightforward with C++ projects, and you can change the 'Platform Toolset' property in the project settings to "Windows7.1SDK" and all is good.
But, with C# projects, (if you put the build output up to diagnostic mode), we can see that various tools such as sgen, resgen, LC, run from within a previous SDK 7.0A directory. Or, on some machines that we installed Vistual Studio 2012 on, some of these tools come from an v8.0A SDK folder.
Mismatches between the tools and the assemblies they produce seem to be causing various errors such as:
LC : error LC0000: 'Could not load file or assembly
'S:\Libraries\Bin\Release\Some.dll' or one of its dependencies. This assembly is built by a runtime newer than the currently loaded runtime and cannot be loaded.'
It seems we can edit the .csproj files and almost ad-hoc, and BeforeBuild etc targets that redefine various SDKPath properties. This seems to force the right tools to be used. But, if feels very 'hacky'. And we must be missing setting something as we still get some errors.
Alternatively, we've found, we can change the registry value here:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\4.0\SDK40ToolsPath
to point at the correct SDK. But, it feels wrong to have to modify the environment to support this. We want to build old versions of our product, and having to switch the environment around to do this is ugly and error prone.
Is there any official way of doing this?
Thanks.
P.S. I found this question http://social.msdn.microsoft.com/Forums/en-MY/windowssdk/thread/ebc8914f-d4b5-44e7-8c76-10332d155812 where the poster seems to be asking a similar thing, but, the question didn't seem to get answered.

The following two articles talk about defining custom tool sets. Perhaps one of those needs defining for the 7.1 SDK, and then MSBuild can be directed to use it.
http://msdn.microsoft.com/en-us/library/bb383796(v=vs.110).aspx
http://msdn.microsoft.com/en-us/library/bb397428.aspx

AssemblyInfo.cs , .net applications versions

I would like to keep version in my .net applications and let the .net to manage it. I don't really understand how it works. Is the version number per project ? How .net manages versions? If anyone could please explain it briefly i will be grateful.

What I usually do is to keep a SolutionInfo.cs that contains all the attributes that are common for the projects of my solution, for example the version-number. I keep this file in the solution root.
I then link that file into the project (right click the project and Add->Exsiting item... -> Add as link (the little arrow on the add button)).
I then can increment the version number in a single place and it will be updated in all the projects that links that file.
For more information on that for example see: http://jebsoft.blogspot.com/2006/04/consistent-version-numbers-across-all.html

The version number is per-project (.csproj file), so per built .dll or .exe file. The version number is embedded in the .dll or .exe, and can be viewed using (for example) Windows Explorer by right-clicking on the file and selecting Properties.
MSDN contains an explanatory article about how to use AssemblyVersion and AssemblyFileVersion at http://support.microsoft.com/kb/556041

[AssemblyVersion] is a very big deal in .NET. Every type in your program is imprinted with the assembly version, it is part of the type identity. In other words, when the version of your type changes then you should also change the assembly version. This forces all other assemblies that use your type to be recompiled.
One thing you can do is to let the build system automatically increment the version. You can't call this 'managing the version' by any stretch of imagination. Because now just rebuilding your assembly, even without making any change in the source code, will make your assembly incompatible with other code that uses the types in that assembly.
Clearly this can only work well if you recompile all the code in your solution.
Well, that's not great unless you like sword fighting. Furthermore, sometimes you want to make a simple bug-fix in your code. The result is an assembly that's still 100% compatible with the original version. And you don't need nor want to recompile everything else that uses it. You just want to send that one assembly to your customer. Clearly that can only work well if you don't let the version increment automatically.
So what you really need is some kind of tool that can magically determine that your source code, the publicly visible part of it, is no longer compatible with a previous version. Or the changes you made to the non-visible part of it are changing the behavior of the code too much to disallow other code that use your types to continue to use it without some changes in their code.
There's only one tool that I know of that can do this, the one we have between our ears.