Add linked DLL references and remove copying #52
Conversation
Took another pass after the last set of improvements to see if I could get something that worked with the regular clean operations
| @@ -12,13 +12,12 @@ | |||
| <AssemblyName>LibSass.NET.Tests</AssemblyName> | |||
| <TargetFrameworkVersion>v4.5</TargetFrameworkVersion> | |||
| <OutputPath>bin\$(Configuration)\</OutputPath> | |||
| <IntermediateOutputPath>bin\$(Configuration)\obj\</IntermediateOutputPath> | |||
| <IntermediateOutputPath>obj\$(Configuration)</IntermediateOutputPath> | |||
There was a problem hiding this comment.
This is intentional to keep everything under bin/.
There was a problem hiding this comment.
What is the reason for that? This is the usual layout for projects.
There was a problem hiding this comment.
It's just better to have one output folder with all the intermediate stuff as normally happens in case of Unix. That's the reason I moved obj in bin during the rewrite. Otherwise, I have no strong preference. :)
There was a problem hiding this comment.
OK, I'm going to leave it for now, but I'll start to look at some of the Core stuff to see what they're doing
There was a problem hiding this comment.
Cool, regarding that, I have been using DNX/Core for over an year now and have survived at least 5 era of upgrades (starting from DNX beta7) 😬. One thing you might notice that there is a lot of stuff already deprecated. So just skip whatever is older than a month or max two months old.
From tooling point of view, the key elements are:
https://github.com/dotnet/cli (command line utility which user and VS are using today to compile projects)
which depends on:
https://github.com/dotnet/core-setup (dotnet.exe aka muxer utility)
and:
https://github.com/dotnet/sdk (where the real magic is happening)
which has another dependent:
https://github.com/dotnet/roslyn-project-system (the new CPS based project system written for VS2017+ and above, see readme for more info)
Note that they are not only .NET Core tools, these tools are made so that they are backward and forward compatible and provide xplat support. For instance, we can potentially configure a project targeting multiple frameworks: v2, v3, v3.5, v4, v4.5, v4.6, netstandard1.1, netstandard1.3, netstandard1.5 and netstandard1.7 and build with a single command dotnet build or msbuild mySolution.sln.
Think of SDK as an API, which CLI and RPS are implementing, but today VS2015 and command line usage, both are consuming the CLI as SDK is comparatively a new abstraction in the OSS toolset.
Also, upcoming msbuild v15 used in VS2017 is based on msbuild repo's default branch xplat instead of master. Both will be merged soon™️ but master which is windows only is irrelevant. MSBuild is not under dotnet org (but Microsoft), as it has non-dotnet usages as well.
We can further the discussion on Slack channel. Question is; are you READY? 😎
| SourceFiles="$(LibSassPath)libsass32.dll;$(LibSassPath)libsass64.dll" | ||
| DestinationFolder="$(OutputPath)" | ||
| SkipUnchangedFiles="true" /> | ||
| </Target> |
There was a problem hiding this comment.
Without copy libsass.dll native to dependent projects, it fails to run.
Just realized the DLL link thingy.
|
Hey, #47 is in progress, can this wait until that goes in? |
| <Link>libsass64.dll</Link> | ||
| <CopyToOutputDirectory>Always</CopyToOutputDirectory> | ||
| </Content> | ||
| </ItemGroup> |
There was a problem hiding this comment.
With #53, we have single libsass.dll now. However, this can be simplified to
<Content Include="$(OutputPath)\libsass.*">* is to provide Unix extension support (.dll -> .so or .dylib etc.)
Took another pass after the last set of improvements to see if I could get something that worked with the regular clean operations
/cc @am11