Open axelheer opened 6 years ago
Okay, let's reproduce this:
wwwroot/css/site.scss
#narf {
display: inline;
}
bmfail.csproj
<Project Sdk="Microsoft.NET.Sdk.Web">
<PropertyGroup>
<TargetFramework>netcoreapp2.0</TargetFramework>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="BuildBundlerMinifier" Version="2.6.375" />
<PackageReference Include="BuildWebCompiler" Version="1.11.375" />
<PackageReference Include="Microsoft.AspNetCore" Version="2.0.2" />
</ItemGroup>
</Project>
bundleconfig.json
[
{
"outputFileName": "wwwroot/css/bundle.css",
"inputFiles": [
"wwwroot/css/site.css"
]
}
]
compilerconfig.json
[
{
"outputFile": "wwwroot/css/site.css",
"inputFile": "wwwroot/css/site.scss"
}
]
Program.cs and Startup.cs from dotnet new
.
Executing dotnet build
fails now on the first run:
C:\Users\TEAH\Projects\bmfail\wwwroot\css\bundle.css : Bundler & Minifier error 0: Could not load file or assembly 'NUglify, Version=1.5.10.0, Culture=neutral, PublicKeyToken=15bc7810aec21b5e'. Could not find or load a specific file. (Exception from HRESULT: 0x80131621) [C:\Users\TEAH\Projects\bmfail\bmfail.csproj]
Executing dotnet build
does not fail afterwards.
Executing dotnet clean
and then dotnet build
fails again.
Maybe it's because WebCompiler uses an older version of NUglify...
Same behavior :( But in our case it's even worst. We using Bundler as part of build pipeline on VSTS, so it's always "new" build, and of course it always failed.
Downgrade to 2.6.362 works fine. Just for reference: version of the BuildWebCompiler 1.11.375
In order to make our TFS build pipeline work, I had to separate compiler and bundler using two extra tasks:
Downgrade is not an option since the upgrade was necessary because of #348 (fixes Bootstrap 4 issues).
So as you @axelheer say - we basically need to get WebCompiler on same version of NUgilfy as BundleMinifier? I'll try to get @madskristensen to look into it.
Yeah, I think so
Any traction on this? Just ran into this problem and now we have some divergent branches. One using the old 2.6.362 which works with our build process but then we are developing on 2.6.375 because it has other fixes :|
We need someone to create PR for WebCompiler - I've tried, but it requires old version of Visual Studio, plus I don't have environment to test results.
So if you are depending on this process - give it a try - fork repo (https://github.com/madskristensen/WebCompiler), update reference to new version of NUglify and submit PR - hordes of us developers will be thankful to you!
Keep in mind new version of NUglify will be coming soon - we need more of those ES6 fixes.
:( 385 still doesn't work. :(
Bundler & Minifier error 0: Could not load file or assembly 'NUglify, Version=1.5.10.0
(But 362 works fine.)
@electricessence yeah - new versions won't work until WebCompiler is updated to same NUglify reference. The only thing that will do until then is workaround @axelheer suggested here: https://github.com/madskristensen/BundlerMinifier/issues/353#issuecomment-383543596
@rockstardev oh ok. So what update should I be looking for? Is it a nuget package or something in VS?
I still encounter this issues during build on both CI environment or running via CLI. Even separating bundler&webcompiler tasks like suggested above did not fixed my issues.
To overcome it I disabled minification in the bundleconfig.json file and now CI tasks & CLI commands don't fail anymore.
Minification being important for my project I've did it as a post-build task using other tools like http://yui.github.io/yuicompressor/
Hello, I have same error but with extension for VS 2019. Any progress with this issue?
Installed product versions
Description
BuildBundlerMinifier msbuild target fails after upgrading from version 2.6.362 to 2.6.375:
This happens only after a "git clean" or just a fresh clone. Thus, we run
dotnet msbuild /t:BundleMinify
on our CI builds (and ignore the error) before the actual build for now.Steps to recreate
This happens only within a bigger solution, I'm currently unable to recreate this with a simple project. Any idea on how to track this down would be appreciated.
Increasing msbuild verbosity does not unveil any insights...
Current behavior
The msbuild task fails on its first attempt, but succeeds on subsequent attempts.
Expected behavior
The msbuild task should succeed on its first attempt.