I have a solution with several MVC6 (asp.net 5) projects.
Each project uses bower and npm for packages. Bower has normalize-css and jquery installed.
9 out of 10 times I start the solution, it will crash during one of the mvc project's initialization-phase. If I debug I get the following error.
An unhandled exception of type 'Newtonsoft.Json.JsonSerializationException' occurred in mscorlib.dll
Additional information: Unexpected end when deserializing object. Path 'dependencies.jquery.pkgMeta.devDependencies', line 43, position 1.
If I remove jquery from bower dependencies and have only normalize-css left I get:
An unhandled exception of type 'Newtonsoft.Json.JsonSerializationException' occurred in mscorlib.dll
Additional information: Unexpected end when deserializing object. Path 'dependencies.normalize-css.pkgMeta._release', line 39, position 1.
I have uninstalled all bower packages and the problem is fixed, but I obviously still need the packages, so when adding jquery or another package again the crashing starts again.
I am using Visual Studio 2015 Enterprise.
edit for bower.json:
{
"name": "ASP.NET",
"private": true,
"dependencies": {
"jquery": "2.1.4",
"normalize-css": "3.0.3"
}
}
Try clean up nuget, npm and bower cache - it's help in my case:
Delete files in your user folder:
..\.dnx\packages\* should be restored automatically, but please make backup first,
..\.nuget\packages\* like above, please make backup first,
..\AppData\Local\bower\cache\*
..\AppData\Roaming\npm-cache\*
..\AppData\Local\Temp\*
Of course close VS before doing this, and VS restore all packages on first running.
Also you can clean up .vs folder in your project folder - theoretically it's not related, but from my experience - it's helping with numbers VS issues.
It seems like fixing another bug, see my answer here: https://stackoverflow.com/a/37331585/2713516 worked wonders for the crashing.
It hasn't crashed since if I recall correctly. Either way, the combination of updating all dll's (especially newtonsoft.json, including removing old versions from disk) and going through the steps suggested by #LukaszDev has definitely made a big change.
Related
I have an ASP.Net MVC project with Angular 13 (upgraded from 8).
v13 is giving me this issue:
core.mjs:4078 JIT compilation failed for NgModule class AppModule {}
core.mjs:4097 Uncaught Error: The NgModule 'AppModule' needs to be compiled using the JIT compiler, but '#angular/compiler' is not available.
I believe that the project is "Lazy Loading" the components:
{
path: 'admin',
loadChildren: async () => await import('./ADMIN/admin.module').then(m => m.AdminModule),
canActivate: [AdminEntitlementGuard]
},
I have stripped out a lot of dependencies that are old and don't have IVY updates.
I'm just at a loss for this core.mjs reference and what I need to do to fix it. I've looked at many of the questions here regarding this error, but none of the solutions have worked. Including updating my package.json file:
"postinstall": "ngcc --properties es2015 browser module main --first-only --create-ivy-entry-points"
I've done an npm update, I've remove the node_modules folder and done an npm install (many times) as well as restarted VS Code (many times).
The one thing that I haven't done, is to set enableIvy=false - which I'm not wanting to do. I want this to work with Ivy.
Is it because of the lazy loading?
Do I need to remove every non #angular dependency to get this to function
I'm really trying to get to the bottom of this so I can rebuild the application if necessary. But I need to know what the core issue. Unfortunately this error message isn't telling me what to fix (at least in my current understanding).
Let me know what you need to see. I have to be careful with copy/pasting code.
I am getting error on debug session start on my dot net core API project; since I updated visual studio to latest version 17.1.1. Following is the exception detail, it is showing on console. I tried by deleting temp, bin, obj folders but nothing worked. Has somebody faced such an issue or know how to fix?
Unhandled exception. System.ObjectDisposedException: Cannot access a disposed object.
Object name: 'ConfigurationManager'.
at Microsoft.Extensions.Configuration.ReferenceCountedProviderManager.AddProvider(IConfigurationProvider provider)
at Microsoft.Extensions.Configuration.ConfigurationManager.AddSource(IConfigurationSource source)
at Microsoft.Extensions.Configuration.ConfigurationManager.Microsoft.Extensions.Configuration.IConfigurationBuilder.Add(IConfigurationSource source)
at Microsoft.AspNetCore.Builder.WebApplicationBuilder.<>c__DisplayClass25_0.b__2(HostBuilderContext context, IServiceCollection services)
at Microsoft.Extensions.Hosting.HostBuilder.CreateServiceProvider()
at Microsoft.Extensions.Hosting.HostBuilder.Build()
at Microsoft.AspNetCore.Builder.WebApplicationBuilder.Build()
at Program.$(String[] args) in Program.cs:line 40
It is because you use the old way of getting the settings from the configuration manager, like:
using (var serviceProvider = services.BuildServiceProvider())
{
...
}
If you remove these lines and just use the configuration as-is with
options = configuration.GetOptions<Object>("xxx");
it will work
we also had this issue since march 8.
is was introduced with the release of 6.0.3, see a github post about the issue : https://github.com/dotnet/aspnetcore/issues/40614
for now what we did is revert to the 6.0.2 version (this is a temporary work around, i will hope to figure out what was wrong asap)
for docker images:
FROM mcr.microsoft.com/dotnet/aspnet:6.0.2 AS base
WORKDIR /app
EXPOSE 80
EXPOSE 443
FROM mcr.microsoft.com/dotnet/sdk:6.0.200 AS build
WORKDIR /src
if you are using it in yml also probably
use dotnetversion
DotNetVersion: "6.0.200" instead of "6.0.x"
6.0.200 is the sdk version of 6.0.2 framework https://dotnet.microsoft.com/en-us/download/dotnet/6.0
11/03/2022
see also this https://github.com/dotnet/core/issues/7259 were i have pinpointed the issue in our code and added a sample app to reproduce
if we look into that repo https://github.com/microsoft/ApplicationInsights-Kubernetes/blob/69f44c6ec3fda26d76a01836b851402e3f8a02ad/src/ApplicationInsights.Kubernetes/Extensions/ApplicationInsightsExtensions.cs
we indeed find the same piece of code on the other answers
i faced to this problem when i update my SDK both in docker and my window 11
my sdk is : 6.0.3
but i cant understand why this problem is happend
I have a sample solution with a console and library project. Both reference the same nuget but a different version. The console project also has a reference to the library project. So the structure is like this:
- Solution
- ConsoleApp
- Project Reference: Library
- Nuget: NServiceBus.RabbitMQ (5.2.0)
- Library
- Nuget: NServiceBus.RabbitMQ (6.0.0)
You can find the solution here.
Since Nuget uses the nearest wins rule, the nuget package that gets resolved is version 5.2.0. This is what I want, so far so good. But when I run the application and run a method of the Library I get the following exception:
Could not load file or assembly 'NServiceBus.Transport.RabbitMQ, Version=6.0.0.0, Culture=neutral, PublicKeyToken=9fc386479f8a226c'. The located assembly's manifest definition does not match the assembly reference. (0x80131040)
In .NET Framework I would solve this with an assembly redirect. But that isn't available in .Net Core. I always thought that .Net Core solves this automatically by using the deps.json file. There I see the following statement:
"Library/1.0.0": {
"dependencies": {
"NServiceBus.RabbitMQ": "5.2.0"
},
"runtime": {
"Library.dll": {}
}
}
But still at runtime he tries to resolve the 6.0.0 version. I'm using the latest .Dot Net 3.1.X SDK.
I'm I doing something wrong or does this seem like a bug?
For the record, this is a simple sample project. The actual situation where I need this is much more complex. I also do understand that doing this can cause runtime exceptions while running the application.
It appears to be by design.
A little bit of searching, I found this: https://github.com/dotnet/fsharp/issues/3408#issuecomment-319466999
The coreclr will load an assembly of the version or higher than the reference. If the assembly discovered is lower than the reference then it fails.
Also this: https://github.com/dotnet/sdk/issues/384#issuecomment-260457776
downgrading the assembly version isn't supported on .NET Core
So, to confirm, I spent much more time than I intended looking/searching through https://github.com/dotnet/runtime. Eventually I found the assembly version compatibility method: https://github.com/dotnet/runtime/blob/172059af6623d04fa0468ec286ab2c240409abe3/src/coreclr/binder/assemblybindercommon.cpp#L49-L53
It checks all the components of the version separately, but if we look at just one, we can see what it's doing:
if (!pFoundVersion->HasMajor() || pRequestedVersion->GetMajor() > pFoundVersion->GetMajor())
{
// - A specific requested version component does not match an unspecified value for the same component in
// the found version, regardless of lesser-order version components
// - Or, the requested version is greater than the found version
return false;
}
As the comment says, the loader will reject the assembly if the assembly's version is lower than the requested version. In your case, assuming that the assembly version matches the package version (which it doesn't have to), your library is requesting version 6.0.0, but the assembly loader/binder, found version 5.2.0 on disk, which is lower. Hence, it rejects that dll, keeps looking, but then can't find a suitable version of the assembly on the probing path and eventually throws the FileLoadException.
What's not clear to me is if this assembly compatibility is checked only on the default assembly loader, or even if you add your own event handler to AssemblyLoadContext.Default.Resolving. You could try adding your own handler and when it requests the assembly of the higher version, you return the lower version assembly anyway. It might be a way to work around the issue.
I have a project at Unity 2019.3 with dotnet 4.x. I am trying to import firebase analicts and I have gotten the following error:
System.TypeInitializationException: The type initializer for 'Firebase.Editor.Measurement' threw an exception. ---> System.MissingMethodException: void Google.EditorMeasurement.set_InstallSourceFilename(string)
--- End of inner exception stack trace ---
at Firebase.Editor.AndroidSettingsChecker..cctor () [0x0000c] in Z:\tmp\tmp.SHkOPK7iEJ\firebase\app\client\unity\editor\src\AndroidAPILevelChecker.cs:37
and
MissingMethodException: void Google.EditorMeasurement.set_InstallSourceFilename(string)
Does anyone have any idea what it could be? Was any library missing? I haven't found reference to this problem anywhere.
I had the exact same problem, I fixed it by fully removing the ExternalDependencyManager folder in the project and replaced it using the latest Jar Resolver plugin from here https://github.com/googlesamples/unity-jar-resolver/blob/master/external-dependency-manager-latest.unitypackage
At the same time I also installed Python 2.7 and added it to system path, but I'm pretty sure the jar resolver thing is what fixed the issue. The root problem is the embedded analytics (EditorMeasurement) fail and Firebase never executes the python scripts that make all the Plugins/Firebase/res/values xmls
Hope this helps! :)
In my case the issue was happening after adding a new Firebase package with a version bigger than the other Firebase packages already in the project. Updating all the packages to the same version solved the problem.
deleting the editor folder inside the PlayServicesResolver folder and then reimporting it from any of the firebase unity packages.
I am using liferay 5.2 sp 2 on weblogic 10.
I need liferay-yuicompressor.jar file in the lib folder of domain.
I am tryign to create .jar file as per described on this link:
http://issues.liferay.com/browse/LPS-3169
When i ant build-yui i am facing below exception.
get-swing-ex:
[mkdir] Created dir: D:\Liferay Material\GOSI\liferay-portal-src-5.2.2\liferay-portal-src-5.2.2\portal-impl\20130301133406114\rhino1_6R7\toolsrc\com\liferay\mozilla\javasc
ript\tools\debugger\downloaded
[get] Getting: http://java.sun.com/products/jfc/tsc/articles/treetable2/downloads/src.zip
[get] To: D:\Liferay Material\GOSI\liferay-portal-src-5.2.2\liferay-portal-src-5.2.2\portal-impl\20130301133406114\rhino1_6R7\toolsrc\com\liferay\mozilla\javascript\tool
s\debugger\downloaded\swingExSrc.zip
[get] http://java.sun.com/products/jfc/tsc/articles/treetable2/downloads/src.zip permanently moved to http://www.oracle.com/technetwork/java/index.html
[unzip] Expanding: D:\Liferay Material\GOSI\liferay-portal-src-5.2.2\liferay-portal-src-5.2.2\portal-impl\20130301133406114\rhino1_6R7\toolsrc\com\liferay\mozilla\javascri
pt\tools\debugger\downloaded\swingExSrc.zip into D:\Liferay Material\GOSI\liferay-portal-src-5.2.2\liferay-portal-src-5.2.2\portal-impl\20130301133406114\rhino1_6R7\toolsrc\co
m\liferay\mozilla\javascript\tools\debugger\downloaded
BUILD FAILED
As per my understanding it is trying to get the .zip file from http://java.sun.com/products/jfc/tsc/articles/treetable2/downloads/src.zip
but it is no longer available and moved to http://www.oracle.com/technetwork/java/index.html
I need your help in getting liferay-yuicompressor.jar file.
Please help me out...
Nakul, I was responding your other post facing exception while deploying liferay on weblogic. Sorry I misunderstood your last comment on that post, as I used LifeRay 6.x, not 5.x.
How about we disable the minification for the runtime so that you do not need to use the liferay-yuicompressor.jar.
You can add the below to portal-ext.properties
javascript.fast.load=false
theme.css.fast.load=false
If you still prefer to do minification for performance reason, you can do it during the build time as described here: http://yui.github.com/yuicompressor/. Between runtime and build time minification, I always prefer build time.
try to comment
<ant antfile="toolsrc/build.xml" target="compile"/>
into the root build.xml
more than that if you will have similiar problems with xbean.jar just set
without-xmlimpl: no
into build.properties file