I have the eShopOnContainers solution here: https://github.com/dotnet-architecture/eShopOnContainers. I have been actively working on a variation of it for the last few years. I attempted to compile it this morning and the WebStatus project causes this error:
libman.json(0,0): Error LIB002: The "jquery#3.4.1" library could not be resolved by the "cdnjs" provider
I have found this: https://github.com/aspnet/LibraryManager/issues/685 and this: https://issuemode.com/issues/cdnjs/cdnjs/94570425 (updated yesterday)
So far I have tried what is suggested in the articles:
dotnet tool install -g Microsoft.Web.LibraryManager.Cli (installs version 2.1.75)
libman cache clean
libman restore
Is there anything else I can try? My Libman.json looks like this:
{
"version": "1.0",
"defaultProvider": "cdnjs",
"libraries": [
{
"library": "jquery#3.4.1",
"destination": "wwwroot/lib/jquery/"
},
{
"provider": "unpkg",
"library": "bootstrap#4.1.3",
"files": [
"dist/css/bootstrap.css",
"dist/css/bootstrap.css.map",
"dist/css/bootstrap.min.css",
"dist/css/bootstrap.min.css.map",
"dist/js/bootstrap.js",
"dist/js/bootstrap.min.js"
],
"destination": "wwwroot/lib/bootstrap/"
}
]
}
Try this:
-Right click libman.json
Disable Client-Side libraries on build
Build the project
Related
I am working on a project using electron and electron-builder. I have implemented deeplinking protocols in my package.json file. after removing the app on windows the deeplinking protocol still persists. I need this to not persist.
i have tried:
1) deleting my %appdata%\program folder as-well
2) restarting my pc after uninstallation.
3) clearing my browser's cache.
{
"name": "program",
//...
"scripts": {
//...
},
"build": {
//...
"protocols": {
"name": "electron-deep-linking",
"schemes": [
"deeplinkingURI"
]
},
"win": {
"artifactName": "program.${ext}",
"target": [
{
"arch": [
"ia32",
"x64"
],
"target": "nsis-web"
}
]
},
//...
},
//...
}
after uninstalling my program, the deeplinking still works (it does not launch the app because it obviously has been uninstalled, but a prompt still appears attempting to launch nothing).
I suspect that something remains within my windows registry.
NOTE: this problem does not occur on macOS
So I've figured out the answer to my own question (not me but colleagues). there is a registry file under computer\HKEY_CLASSES_ROOT\deeplinkingurl that must be deleted at uninstall via script.
there is another question (that i did not see before, forgive me) that gives more details.
Visual Studio (2015) is underlining all my references to "Model" in the Class Library Razor views and giving this error message:
The name "Model" does not exist in the current context
I have seen a lot of questions asking this sort of thing in an earlier version of ASP.Net and MVC but not much for this version.
Since these Razor views are setup as an embedded resource they are compiling fine and running fine. They just give me errors in the editor.
In the project.json file I have a reference to Razor Tools that I thought should fix this:
"dependencies": {
"ApolloWeb.Common": "1.0.0-*",
"Microsoft.AspNet.Mvc": "5.2.3",
"Microsoft.AspNetCore.Mvc.ViewFeatures": "1.0.1",
"Microsoft.AspNetCore.Razor.Tools": {
"version": "1.0.0-preview2-final",
"type": "build"
},
"Microsoft.Extensions.FileProviders.Embedded": "1.0.0",
"NETStandard.Library": "1.6.1-preview1-24530-04"
},
"tools": {
"Microsoft.AspNetCore.Razor.Tools": "1.0.0-preview2-final"
},
"frameworks": {
"net46": {}
},
"buildOptions": {
"embed": [ "_Views/**" ],
"preserveCompilationContext": true
}
I have discovered what my issue was.
I copied all the packages that the MVC template pulled into the Main MVC project and started removing them until I reached the one that reproduced the issue.
I was missing a dependency on this package:
"Microsoft.AspNetCore.Mvc": "1.0.1",
I am running into some performance issues trying to run the chutzpah.console.exe with my chutzpah.json file. For this project, I am using TypeScript and pre-compiling the TypeScript files into .js files before running the tests. Each test file that I have generally references one other TypeScript file that it depends on - this is so Visual Studio is happy and so that the Chutzpah extensions work. For example, my drawerBusiness.spec.ts file contains this reference:
/// <reference path="../../../../app/business/documents/drawerBusiness.ts"/>
My chutzpah.json file is as follows:
{
"Compile": {
"Mode": "External",
"Extensions": [ ".ts" ],
"ExtensionsWithNoOutput": [ ".d.ts" ]
},
"Framework": "jasmine",
"TestHarnessReferenceMode": "Normal",
"TestHarnessLocationMode": "SettingsFileAdjacent",
"References": [
{ "Path": "./lib/jquery/jquery.js" },
{ "Path": "./lib/angular/angular.js" },
{ "Path": "./lib/angular-mocks/angular-mocks.js" },
{ "Path": "./lib/jasmine-jquery/jasmine-jquery.js" },
{ "Path": "./lib/underscore/underscore.js" },
{ "Path": "./lib/angular-bootstrap/ui-bootstrap-tpls.js" },
{ "Path": "./tests/dependencies.js" }
],
"Tests": [
{ "Include": "*/tests/specs/*.ts", "ExpandReferenceComments": "true" }
]
}
As you can see from above, I need to load some external libraries. I presume these get loaded once and then are used for each of the tests?
When I was using pure JavaScript, this configuration was blazing fast. It completed quite quickly in Visual Studio and through running the tests from the chutzpah.console.exe. However, since I have switched over to Chutzpah, the tests are much slower:
Tests complete: 263
=== 263 total, 0 failed, took 74.64 seconds ===
These results are even worse on our build machine, and it's timing out. It seems like there's a huge delay between each spec file that is run, and I think that is causing the overall slowness - once the spec file starts running, it completes in a few one-hundredths of a second. Does anyone have any ideas about what could possibly be configured incorrectly?
Here are a few things you can try to help get to the bottom of this issue:
Can you try enableding "EnableTestFileBatching": true in your chutzpah.json file to see if it helps? There can be slowness if you have MANY test files and this setting tells chutzpah to batching them into one harness.
Can you provide the output of the /trace option so I can see all the timings?
Can you provide a repro that I can run locally?
I'm trying to create some tasks in Visual Studio Code to run all the tests in my go project.
I usually execute the tests on the command line using:
go test ./...
In Visual Studio Code my tasks.json looks like this:
{
"version": "0.1.0",
"command": "go",
"tasks": [
{
"taskName": "build",
"isBuildCommand": true
},
{
"taskName": "test",
"isTestCommand": true,
"args": ["./..."]
}
]
}
So Build works fine (CTRL + SHIFT + B)
But when I try to run the tests (CTRL + SHIFT + T) the following error occurs:
go: unknown subcommand "./..."
It seems to be omitting the "test" param, but when I comment out the args it runs go test fine.
Any ideas?
THIS MAY BE A BUG
VSCode Reverse Args and Task as of v0.8.0
This may be a bug that still persists in the newer versions. As of v0.9.1 I have not had a chance to test. Prior to 0.9.1 at least one hack worked by reversing the task and it's arg as in the following example:
{
"version": "0.1.0",
"command": "go",
"tasks": [
{
"taskName": "build",
"isBuildCommand": true
},
{
"taskName": "./...",
"isTestCommand": true,
"args": ["test"]
}
]
}
It's hard to believe that this has still persisted until v0.8.0 so there may be a preferred solution that I have not discovered.
Here is a link to a prior post that deals with a similar issue:
Define multiple tasks in VSCode
Scroll down to my answer for more explanation.
I'm using the "Marionette-Require-Boilerplate" (https://github.com/BoilerplateMVC/Marionette-Require-Boilerplate) to build my app, which also uses Firebase and FirebaseSimpleLogin. They are working fine in 'development' mode, but when it's time to minify it into 'Production' mode using Grunt and running in the browser, the minified version will have trouble finding the Firebase libraries, spitting out an error saying firebase is not defined. Both the Firebase and FirebaseSimpleLogin libs have been included in the config file as followed:
paths:{
"firebase" : "../libs/firebase",
"firebase-simple-login" : "../libs/firebase-simple-login",
"backbone-firebase" : "../libs/backbone-firebase",
}
shim: {
"firebase": {
"exports": "Firebase"
},
"firebase-simple-login": {
"exports": "FirebaseSimpleLogin"
},
"backbone-firebase": {
"deps": ["backbone", "firebase"],
"exports": "backbone-firebase"
}
}
It seems like the Boilerplate is minifying the code using Almond.js in 'production mode', but I'm not sure how that's affecting it. I tried including the Firebase libs in the 'path' variable in Grunt.js, but that didn't do anything.
Any help is appreciated!
Thanks.
-Tony
You shouldn't be minifying the already minified Firebase sources - that will cause trouble. You should skip minification for firebase.js (and simple login).
Thanks to the Firebase Support Team in solving the problem. The solution is to remove the "exports" from the "backbone-firebase" shim as there's no such thing as "backbone-firebase"; it is part of the "Backbone" namespace, e.g. Backbone.Firebase.Colection. Require.js was looking for something that is called "backbone-firebase" while non exists. Once the "exports" is removed, Require.js works correctly during the minification.
shim: {
"firebase": {
"exports": "Firebase"
},
"firebase-simple-login": {
"exports": "FirebaseSimpleLogin"
},
"backbone-firebase": {
"deps": ["backbone", "firebase"]
}
}