I am trying to add Sass files to my .NET Core application in Visual Studio 2017. However, I cannot find any way to compile .scss files once I've made them. I sifted through NPM and Bower, but neither offer support for Sass.
The Microsoft documentation for adding Sass (https://learn.microsoft.com/en-us/aspnet/core/client-side/less-sass-fa) is outdated, and assumes that the project has a package.json file. Any guidance on enabling Sass compiling for my project would be much appreciated.
The easiest way to add .scss to your ASP.NET Core apps is by going to the Nuget Package Manager and installing LigerShark.WebOptimizer.Core and LigerShark.WebOptimizer.Sass.
After that, you can just put
<link rel="stylesheet" href="~/css/site.scss" />
in the head of the _Layout.cshtml file and the LigerShark.WebOptimizer.Sass package will compile all of your sass files automatically.
Use this extension for Visual Studio https://marketplace.visualstudio.com/items?itemName=MadsKristensen.WebCompiler
This extension not only lets you manually compile SASS/SCSS files to CSS, but it also adds a compilerconfig.json which can recompile your CSS every single time you click save.
Additionally, this extension can compile on project build via a nuget package it can install into your project. Which also enables CI/CD support.
This is by far the easiest way to add SCSS/SASS compilation to an ASP.NET Core Project when working inside of Visual Studio.
Try the article How to use Sass in ASP.NET Core 2.0 MVC
If I understood correctly, you can create a blank project.json with node package manager. And you can also configure auto build event with grunt.
Or better yet, follow this tutorial and manually add the file project.json to the project:
https://learn.microsoft.com/en-us/aspnet/core/client-side/less-sass-fa
(retired doc page, now redirects to fontawesome)
Seems that you have missed this part (that file should be created manually):
If you want SCSS compilation and bundling in one simple tool, try NBundle. (Apologies for the shameless self-plug!)
You specify which files to monitor (wildcards allowed) and the tool can be used to generate compiled and bundled files in a one-shot or "watcher" mode where output files are generated when the source files are saved.
How to accomplish this might depend on your workflow. I'd like it to be part of the build process as seamlessly as possible. So my prefered solution is using a dotnet tool called excubo.webcompiler(no I'm not affiliated in any way with the author). If you install it as a project tool
dotnet tool install Excubo.WebCompiler
you can add a simple target to your project file.
<Target Name="CompileStaticAssets" AfterTargets="AfterBuild">
<Exec Command="dotnet webcompiler -r wwwroot" StandardOutputImportance="high" />
</Target>
That will use the default settings which will often be sufficient. If not you can tweak the process using a configuration file
You simply need to add a package.json think you getting confused with project.json which was the old project system for .net core projects prior to switching back to .csproj
You can use live SASS compiler for compiling SCSS to CSS when the build occurs.
You have to add few line in the .csproj file and prior to that install live sass compiler from npm.
Here is my blog post: How to Use SCSS with ASP.NET Core 5.X or 3.X
Related
I have a C# solution with VS 2017, containing an app project, a desktop extension project, and a packaging project. As I mentioned in the answer of this question, I finally get msbuild to create a single bundle with both x86 and x64 for me. However, after I tried to install from that bundle, I found that msbuild actually picked up the wrong package.appxmanifest because they have different version numbers.
So... I have two package.appxmanifest, one in packaging project, and one in my main app project. When I build from the wizard in VS 2017, the one in packaging project will be used, which is correct. When I use msbuild to build with just one platform, it will pick the right one as well, like this:
msbuild .\MyApp.sln /p:Configuration=Release /p:Platform=x86
Only when I use msbuild to build two platforms together, it will use the one in my main app project:
msbuild .\MyApp.sln /p:Configuration=Release /p:AppxBundlePlatforms="x86|x64" /p:UapAppxPackageBuildMode=StoreUpload
I also tried to build the packaging project instead of the solution, but because our desktop extension project is only x86, I will get errors about configurations when building x64.
Questions:
Does anyone know why this is happening?
I am also very confused about how to build multi-platform using AppxBundlePlatforms in the command line. Since I cannot specify the platform, which platform is used to build?
Should I add <AppxBundle>Always</AppxBundle> or <AppxBundle>Never</AppxBundle> to the packaging project?
Does anyone know why this is happening?
That because you have two Package.appxmanifest files with same ID in the solution. When you create the App Bundle with .sln, MSBuild/Visual Studio could not to know clearly which Package.appxmanifest should be use.
I am also very confused about how to build multi-platform using AppxBundlePlatforms in the command line. Since I cannot specify the
platform, which platform is used to build?
Not sure the reason why you can not specify the platform. To resolve this issue, you can try yo build the project file .csproj instead of the solution file. For example, when you build the app project, you can use the command line:
msbuild .\MyApp.csproj /p:Configuration=Release /p:AppxBundlePlatforms="x86|x64"
And then build the packaging project:
msbuild .\YouPackaging.csproj /p:Configuration=Release /p:AppxBundlePlatforms="x86"
Should I add Always or
Never to the packaging project?
If you build the project, no need to add those two properties to the project file, those two properties are used to the solution level and you have a project that you do not want to add to the bundle:
because at the solution level, it’s not clear which app should appear
in the bundle. To resolve this issue, open each project file and add
the following properties at the end of the first
element
Hope this helps.
I'm not able to copy the content static files in my .Net core web application project that I added when creating the nuget package using nuget package explorer. Same thing get copied correctly in .Net framework project template but not in .net core template. I'm using VS 2015 update 3.Am i Missing something here? Any help would be greatly appreciated.
Below is my snapshot of content file structure.
There is a nuget blog post about this, and it just isn't supported at this time.
Supported Project Types
This feature is only for packages that will be installed to projects that are managed using a project.json file. Currently only two projects types are managed by a project.json.
UWP apps
Portable class libraries
The contentFiles option is not available for other project types.
It's really a pity this basic functionality has been excluded from the .net Core projects. Especially because PCL is supported, which is a subset of a .net Core project.
There are quite some issues on GitHub about this, and it's very unclear whether or not this feature is coming back any time soon.
It seems it is still not supported. Only way to "hack" it is with MSBuild Targets and Build events.
According to this documentation:
build
MSBuild .targets and .props files Automatically inserted into
the project file or project.lock.json (NuGet 3.x+).
So to make it work with any file, e.g.: "config.xml" as Nuget Static Content:
Create your XY.nuspec file (as you would normally)
Include config.xml into the Nuget: <file src="config.xml" target="contentFiles\any\any\config.xml" />
Add a new .targets file XY.targets
Include new XY.targets file into your package to the "build" folder. <file src="XY.targets" target="build"/>
Content of the XY.targets file
<?xml version="1.0" encoding="utf-8"?>
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<ContentFilesPath>$(MSBuildThisFileDirectory)..\contentFiles\any\any\</ContentFilesPath>
</PropertyGroup>
<Target Name="CopyConfigs" BeforeTargets="PreBuildEvent">
<Copy SourceFiles="$(ContentFilesPath)\config.xml" DestinationFiles="$(ProjectDir)config.xml" SkipUnchangedFiles="true" Condition="!Exists('$(ProjectDir)config.xml')"></Copy>
</Target>
</Project>
After packaging and installing the Nuget this MSBuild Target will be part of the Cached package and will run on each build (currently before build).
Issues with this solution:
Added files still linked until you build your solution. During the build paheses (BeforeTargets="") files are copied. Until this files still are just linked!!!
If you set up your content files to have Build actions and be copied to the Output directory of the project those settings will be lost!
Unfortunately this is the best solution for now.
Some public nuget packages (e.g. https://www.nuget.org/packages/NUnit3TestAdapter/3.10.0 or https://www.nuget.org/packages/Selenium.WebDriver.ChromeDriver/) can copy files. I've tried to investigate it (https://github.com/nunit/nunit3-vs-adapter and https://github.com/jsakamoto/nupkg-selenium-webdriver-chromedriver). But it seems, they have implemented very tricky workaround
After reading this post I came up with a work around. I created a .Net assembly project and completely emptied it out of all content. Then I moved the project into the same directory as the project for the .Net Core Web application. Instead of adding the NuGet package reference from the web application, I add it from the .Net assembly project. All of the files are correctly copied into the directory and are automatically added to the web project, since they share the same directory. This solution feels very dirty, but it is allowing me to manage static files with a NuGet package for a .Net Core Web project.
Before Visual Studio 2015, it was trivial to setup your project to automatically generate NuGet packages. Specifically, you did:
Add a .nuspec file to your project
Enable NuGet Package Restore in the Solution right-click context menu
Edit the project .csproj file and set the build property <BuildPackage> to true
And that was it!
However, starting from VS 2015, MSBuild-integrated package restore has been removed and replaced by the new Automatic Package Restore. While these are all good news, it seems that setting the build property <BuildPackage> to true no longer triggers an automatic package build.
This is a major break of functionality! Is there a way to setup automatic builds of NuGet without using post-build events? Specifically, I'm looking for an MSBuild solution, as it forms the backbone of my build workflow.
Try OctoPack: https://www.nuget.org/packages/OctoPack/
Just add nuget package to your project.
If you want to build it every time you build release, add
to section <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|Whatever' ">
next line:
<RunOctoPack>true</RunOctoPack>
More information about finetuning can be found here: https://github.com/OctopusDeploy/OctoPack
There is a move to Class Library Packages in VS2015 which makes it incredibly easy to create NuGet packages. I've blogged about this before, but essentially it's just a few steps. Note that this is just a RC1 at the moment and not a stable release yet.
Install the ASP.NET and Web Tools 2015 (RC1 Update 1) update to VS2015.
Open VS2015 and create a new Class Library Package project.
Add your code to the library and configure the project.json file with any changes you may need. A default project.json file is used as an example.
Right-click on the project and select the Properties menu item. In the Build tab select “Produce outputs on build”. Build the project.
You’re done. Go to the artifacts folder in your project, in my case “artifacts\bin\AwesomeSoft.TextConverter\Debug”.
You should see the NuGet package already created, and the folders targeting each framework specified earlier.
There is another alternative called NuPack :
How-to-create-a-nuget-package-on-each-Visual-Studio-with-NuPack
It is a nuget package that automatically generate nuget package on build time.
VS4MAc already supports this and you can get it as a extension for VS on Windows
https://github.com/NuGet/NuGet.Build.Packaging
When I looked at the tutorials of MVC6, I get confused the usage of project.json. By my understanding this file is used to specify the project dependencies.
Prior to ASP.NET 5, we use nuget to manage the dependencies. But from some limited MVC6 samples I have seen I don't see people mention package.config any more.
Please help me to understand:
Do we still use nuget to upgrade all depending components?
Or we have to modify the project.json manually?
By my understanding [project.json] is used to specify the project dependencies.
Yes. One of the main functions of project.json is to manage server-side dependencies. (It also specifies other project specific settings.) See the project.json file for more info.
Prior to ASP.NET 5, we use nuget to manage the dependencies.
Yes again. And, ASP.NET 5 still uses NuGet to manage dependencies. The configuration differs though. Instead of using packages.config we use project.json > dependencies to list our project's NuGet packages (and other local dependencies.)
...from some limited MVC6 samples I have seen I don't see people mention package.config any more.
Yes again. Instead of package.config, ASP.NET 5 lists all dependencies, including NuGet packages, within project.json > dependencies. These dependencies can be NuGet packages, local assemblies, or local projects.
To expand on this, in Visual Studio, the References folder is a reflection of our project.json > dependencies section. What we add to the one will appear in the other. See server-side dependency management.
In some ways, you can think of the References folder as a GUI view of project.json > dependencies. For instance, here is a dependencies section from one of my projects alongside the References folder.
Note the one-to-one correspondence between what is listed in project.json and in the References folder (ignore the fx/ stuff that isn't in dependencies).
Note the the icons beside the items that References lists. These indicate whether the reference is a project, NuGet package (blue), or assembly.
Do we still use nuget to upgrade all depending components?
Yes. We just use it differently. If we add a NuGet package to our project.json - either manually or via the GUI's package manager - then we will restore/update those using the NuGet feed.
Or [do] we have to modify the project.json manually?
No. You can modify project.json manually but there are two mains ways to add NuGet packages. Which you use is personal preference.
Edit the project.json file manually.
Use the Visual Studio GUI.
Use the Visual Studio Code GUI.
Importantly, what you do to via the GUI will be reflected in the project.json file, and what you do to project.json > dependencies will be reflected in the GUI.
Do we still use nuget to upgrade all depending components?
The short answer is yes.
We have to modify the project.json manually?
You could also do that.
You can really do anything you want:
You could use the nuget package manager UI.
You could use nuget CLI through the Package Manager Console.
Or, you could even add, remove, change dependencies by modifying the project.json which has a really nice auto-complete like in the Package Manager Console.
The only difference now is that there isn't any mention of the installed packages in the project file (previously *.csproj), so yo don't have to add the references manually like when we had the packages.config.
Do we still use nuget to upgrade all depending components
No, you can just add them by your hand with the versions. Most of the IDEs and code editors has support for nuget dependency auto-complete inside project.json file.
More info on project.json file: https://github.com/aspnet/Home/wiki/Project.json-file (could be a little outdated).
More info on DNX dependencies: http://docs.asp.net/en/latest/dnx/overview.html?highlight=project#dependencies
I am pretty new to msbuild and aspnet_compiler.
I am using aspnet_compiler to compile web application project. Now I just saw the MSBuild.exe and noticed that its builds my website into the /mywebsite/precompiledWeb folder. Now why do I need to use MSBuild.exe? Can't I directly use the aspnet_compiler to see if my website can be built properly?
(Not sure if I explained it very well).
msbuild.exe is usually used to build projects and its dependencies. When you have a web application project with a project file, vs can use this to build not only your web project but all the dependencies involved. This would only build your source code files, not the markup files (.aspx,.ascx,.etc).
aspnet_compiler is meant to build a web site project that doesn't have a project file. This said, you can also use it to make sure your markup files are also built for your web application project.
You are correct you can manually invoke the aspnet_compiler.exe tool. But better would be to use Web Deployment Projects to help you do this.