I started with Among Us mod making a few days ago, I set everything up and followed the instructions listed on this page (https://docs.reactor.gg/docs/) and everything worked. I could build my mods and it would work as intended. 2 days ago, out of the blue all of my imports (like the UnityEngine import and other external imports) were throwing 'does not exist in this current context errors' The root of this (I found) was this:
Severity Code Description Project File Line Suppression State
Error MSB4018 The "GenerateReferences" task failed unexpectedly.
System.IO.FileNotFoundException: Could not load file or assembly 'Mono.Cecil, Version=0.11.2.0, Culture=neutral, PublicKeyToken=50cebf1cceb9d05e' or one of its dependencies. The system cannot find the file specified.
File name: 'Mono.Cecil, Version=0.11.2.0, Culture=neutral, PublicKeyToken=50cebf1cceb9d05e'
at Il2CppDumper.DummyAssemblyExporter.Export(Il2CppExecutor il2CppExecutor, String outputDir, Boolean addToken)
at Il2CppDumper.Il2CppDumper.PerformDump(String gameAssemblyPath, String metadataDatPath, String outputDirectoryPath, Config config, Action`1 reportProgressAction)
at Reactor.OxygenFilter.MSBuild.GenerateReferences.Execute() in /home/js6pak/Development/AmongUs/Reactor.OxygenFilter/Reactor.OxygenFilter.MSBuild/GenerateReferences.cs:line 56
at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute()
at Microsoft.Build.BackEnd.TaskBuilder.d__26.MoveNext()
WRN: Assembly binding logging is turned OFF.
To enable assembly bind failure logging, set the registry value [HKLM\Software\Microsoft\Fusion!EnableLog] (DWORD) to 1.
Note: There is some performance penalty associated with assembly bind failure logging.
To turn this feature off, remove the registry value [HKLM\Software\Microsoft\Fusion!EnableLog].REDACTED.REDACTED]
I have tried reimporting, and redoing everything from scratch (like redownloading BepinEx, Reactor, Among Us) and have also tried building a fresh project, but even new projects don't seem to build. Is there something wrong on my part?
Turns out, I had to downgrade my Among Us version. The way I downgraded the version was using Docker, but I suppose any other way could work.
Related
I got the below error when I try to open up an SQLiteConnection using System.Data.SQLite
System.DllNotFoundException: Unable to load shared library 'SQLite.Interop.dll' or one of its dependencies.
In order to help diagnose loading problems, consider setting the DYLD_PRINT_LIBRARIES environment variable: dlopen(libSQLite.Interop.dll, 0x0001): tried: 'libSQLite.Interop.dll' (no such file),
'/usr/local/lib/libSQLite.Interop.dll'
(mach-o file, but is an incompatible architecture
(have 'x86_64', need 'arm64e')), '/usr/lib/libSQLite.Interop.dll' (no such file)
I had the same issue. After some search on google, it seems that the implementaion on M1 is not yet done.
https://sqlite.org/forum/info/f985511fd94fb44cd77465195f88416631590cb3cee84003f9d8561c8e2a58fe
I've managed to boil down my test to a simple command:
PS C:\Users\CpUser> [System.Reflection.Assembly]::LoadFrom("C:\Users\CpUser\.nuget\packages\njsonschema\10.4.0\lib\net45\NJsonSchema.dll")
MethodInvocationException: Exception calling "LoadFrom" with "1" argument(s): "Could not load file or assembly 'NJsonSchema, Version=10.4.0.0, Culture=neutral, PublicKeyToken=c2f9c3bdfae56102'."
I'm using 64-bit Powershell v7.1.3 on Windows 10. Ran as administrator. It's not able to load the DLL I gave it, which is very odd to me. It also does not give me any detail as to why it cannot load it. When I try a lower version of NJsonSchema.dll, it works, but it loads it from an unexpected location:
PS C:\Users\CpUser> [System.Reflection.Assembly]::LoadFrom("C:\Users\CpUser\.nuget\packages\njsonschema\9.10.52\lib\net45\NJsonSchema.dll")
GAC Version Location
--- ------- --------
False v4.0.30319 C:\Program Files\PowerShell\7\NJsonSchema.dll
It's loading it from C:\Program Files\Powershell\7 which seems wrong to me. I sent to the Properties -> Details of that DLL and it says it is version 10.2.2. What it seems like is happening here is:
Powershell takes the version of the assembly I provided in the LoadFrom() call
It searches C:\Program Files\PowerShell\7 for the same DLL with a version equal to or greater than the version obtained in the previous step
If not found, fail.
What I expect is for it to load the DLL using the absolute path I gave it.
As a workaround, I found another solution that does seem to work:
$AssemblyPath = "C:\Users\CpUser\.nuget\packages\njsonschema\10.4.0\lib\net45\NJsonSchema.dll"
$bytes = [System.IO.File]::ReadAllBytes($AssemblyPath)
[System.Reflection.Assembly]::Load($bytes)
I get a successful result when I run the above in a script:
PS C:\Users\CpUser> .\testLoadDll.ps1
GAC Version Location
--- ------- --------
False v4.0.30319
So I feel like this rules out any issues with the DLL itself. I'm completely lost here. Can someone explain the behavior I'm seeing and how to get the behavior I expect?
According to the documentation, for Assembly.LoadFrom Method
The LoadFrom method has the following disadvantages. Consider using
Load instead.
...
If an assembly is loaded with LoadFrom, and the probing path includes
an assembly with the same identity but a different location, an
InvalidCastException, MissingMethodException, or other unexpected
behavior can occur.
Update:
According to Resolving PowerShell module assembly dependency conflicts,
PowerShell and .NET
PowerShell runs on the .NET platform. NET is ultimately responsible
for resolving and loading assembly dependencies, so we must understand
how .NET operates here to understand dependency conflicts.
We must also confront the fact that different versions of PowerShell
run on different .NET implementations. In general, PowerShell 5.1 and
below run on .NET Framework, while PowerShell 6 and above run on .NET
Core. These two implementations of .NET load and handle assemblies
differently. This means that resolving dependency conflicts can vary
depending on the underlying .NET platform.
Therefore, ensure you are loading the DLL in the netstandard2.0 folder, if using Powershell version 6 and above.
Try the following:
Open PowerShell version 7.1.3:
In "Type here to search" box, enter pwsh
Right-click PowerShell 7 (x64)
Select Run as administrator
Get PowerShell version:
Get-Host | Select-Object Version
Get Loaded Assemblies:
[System.AppDomain]::CurrentDomain.GetAssemblies()
Load NJsonSchema.dll:
Note: Since we're using PowerShell 7.x.x, use the NJsonSchema.dll file in the netstandard2.0 folder.
$Assembly = [System.Reflection.Assembly]::Loadfile('C:\Users\CpUser\.nuget\packages\njsonschema\10.4.0\lib\netstandard2.0\NJsonSchema.dll')
Get Loaded Assemblies (again):
[System.AppDomain]::CurrentDomain.GetAssemblies()
Check the version of NJsonSchema.dll:
$Assembly.GetName()
When running BenchmarkDotNet for a method in my project I get a few "Wrong assembly binding redirect" warning/error messages printed to screen. This got me a bit puzzled, as I thought assembly binding redirects is a .Net Framework concept, while my projects are .Net Core 3.0. Googling the warning/error message gave no result. Any tips to what these messages mean, and possibly how to fix the problem. I tried cleaning Nuget cache, restoring Nuget packages, cleaning and rebuilding the solution, but to no help.
// BeforeAnythingElse
// Benchmark Process Environment Information:
// Runtime=.NET Core 3.0.0 (CoreCLR 4.700.19.46205, CoreFX 4.700.19.46214), X64 RyuJIT
// GC=Concurrent Workstation
// Job: DefaultJob
OverheadJitting 1: 1 op, 308100.00 ns, 308.1000 us/op
// Wrong assembly binding redirects for System.Data.Common.resources, Version=4.2.1.0, Culture=en-US, PublicKeyToken=b03f5f7f11d50a3a.
// Wrong assembly binding redirects for System.Data.Common.resources, Version=4.2.1.0, Culture=en, PublicKeyToken=b03f5f7f11d50a3a.
// Wrong assembly binding redirects for System.Data.SqlClient.resources, Version=4.6.0.0, Culture=en-US, PublicKeyToken=b03f5f7f11d50a3a.
// Wrong assembly binding redirects for System.Data.SqlClient.resources, Version=4.6.0.0, Culture=en, PublicKeyToken=b03f5f7f11d50a3a.
// Wrong assembly binding redirects for System.Private.Xml.resources, Version=4.0.1.0, Culture=en-US, PublicKeyToken=cc7b13ffcd2ddd51.
// Wrong assembly binding redirects for System.Private.Xml.resources, Version=4.0.1.0, Culture=en, PublicKeyToken=cc7b13ffcd2ddd51.
The short answer is that you can ignore this warning.
The long answer: for some reason VS sometimes generates invalid assembly binding redirects for Full .NET Framework projects that reference .NET Standard libraries. It was causing a lot of trouble to BenchmarkDotNet users in the past:
https://github.com/dotnet/BenchmarkDotNet/issues/895,
https://github.com/dotnet/BenchmarkDotNet/issues/667,
https://github.com/dotnet/BenchmarkDotNet/issues/896,
https://github.com/dotnet/BenchmarkDotNet/issues/942 .
I decided to implement an ugly workaround that searches for .dll file manually and loads it when .NET Framework fails to do so.
Of course, this applies only to Full .NET Framework. When I was porting BenchmarkDotNet to .NET Standard 2.0 I've forgotten that we don't need to do this for .NET Core. As the end result, you get this confusing warning.
I've sent a PR that fixes that: https://github.com/dotnet/BenchmarkDotNet/pull/1365 and this workaround will now be executed only for Full .NET Framework projects
I am trying to deploy my solution package (wsp) to SharePoint 2007 environment. The WSP contains a feature which loads the feature receiver class to deploy a timer job at run time.
While deploying this WSP, I am consistently getting
Feature
'fb631f6c-2c46-4ab5-b7b3-f3d0c949c5f0'
could not be installed because the
loading of event receiver assembly
"XXX, Version=1.0.0.0,
Culture=neutral,
PublicKeyToken=bad6857072694970"
failed:
System.IO.FileNotFoundException
I have double checked everything (public key token, assembly name etc) is correct. I have deployed many WSP in past and I am confused why this one is failing.
To debug this , I am using Assembly Binding Log Viewer. I have selected "Log in exception text" and given custom log path. Neither I am getting any log messages and the exception text is consistently giving this message:
WRN: Assembly binding logging is
turned OFF. To enable assembly bind
failure logging, set the registry
value
[HKLM\Software\Microsoft\Fusion!EnableLog]
(DWORD) to 1. Note: There is some
performance penalty associated with
assembly bind failure logging. To
turn this feature off, remove the
registry value
[HKLM\Software\Microsoft\Fusion!EnableLog].
Any ideas why this could be happening ? How to enable Assembly Binding Log viewing?
To turn the logging on use Regedit and updated the registry entry in the error message.
It could be that your program requires a dll that is not included in the package.
Sometimes it just needs an IISRESET to realise that the dll is available in the GAC.
When I run my Unit Tests, all tests pass, but instead of "Test run succeeded" or whatever the success message is, I get "Test run error" in the little bar that tells me how many of my tests pass, even though all my tests passed.
When i click the text, I'm taken to a page that tells me the following two things happened:
Warning: conflict during test run deployment: deployment item '[...]\Booking.Web.dll' directly or indirectly referenced by the test container [...]\Booking.Web.Tests.dll cannot be deployed to 'Booking.Web.dll' because otherwise the file '[...]\Booking.Web.dll' would override deployment item '[...]\Booking.Web.dll' directly or indirectly referenced by '[...]\Booking.Web.Tests.dll'
Error: Cannot initialize the ASP.NET project 'Booking.Web'
Exception was thrown: The website could not be configured correctly; getting ASP.NET proccess information failed. Requesting 'http://localhost:54131/VSEnterpriseHelper.axd' returned an error: The remote server returned an error: (500) Internal Server Error.
I don't understand half of what it's complaining about. How do I get rid of these errors?
(And for reference: Booking.Web is an ASP.NET MVC 2 project, Booking.Web.Tests is a Test project, [...] is the full local path to the projects in my environment, in most of the cases above to the /bin/debug/ folder inside the Booking.Web project)
Update: As instructed, I looked for more info in Event Viewer. Here's what I found:
3008
A configuration error has occurred.
5/8/2010 2:26:15 AM
5/8/2010 12:26:15 AM
4ffbe9180c3d4c02adb9ac4d61dd0928
1
1
0
4484bbf4-1-129177519750954331
Full
/
D:\...\Booking.Web\
AASLOEG
1876
WebDev.WebServer40.EXE
Aasloeg\Tomas
ConfigurationErrorsException
Could not load file or assembly 'Ninject.Web.Mvc, Version=2.0.0.0, Culture=neutral, PublicKeyToken=79764a4ef1548af1' or one of its dependencies. Strong name signature could not be verified. The assembly may have been tampered with, or it was delay signed but not fully signed with the correct private key. (Exception from HRESULT: 0x80131045) at
System.Web.Configuration.CompilationSection.LoadAssemblyHelper(String assemblyName, Boolean starDirective) at
System.Web.Configuration.CompilationSection.LoadAllAssembliesFromAppDomainBinDirectory() at
System.Web.Configuration.CompilationSection.LoadAssembly(AssemblyInfo ai) at
System.Web.Compilation.BuildManager.GetReferencedAssemblies(CompilationSection compConfig) at
...stack trace in absurdum.
First of all - you have Code Coverage enabled. You can read here about it. So there is no problems with Unit Tests. This is code coverage problem.
Second thing - this warning is ok - never mind about it.
Third thing - this error - this is the key problem.
There can be different problems - most common is that you should refference more assemblies. To find out what exactly should be loaded you must go to Event Viewer and look at at Windows Logs->Application
I had the same error related to MS-Test complaining that a DLL could "override deployment item blah.dll".
This was happening because I was running MS-Test for multiple DLL's at once like so:
mstest.exe /testcontainer:Tests.web.dll /testcontainer:Tests.svcs.dll /testcontainer:Tests.core.dll
When MS-Test was running this, it tried to take all the output DLL's from the tests and place them in out /Out directory of the test run. In my case, Tests.svcs.dll and Tests.core.dll both referenced the same assembly (Core.dll) and therefore it tried to copy that DLL to the same spot twice (thus causing the warning).
To resolve this, I separated the test runs for each assembly which gave each test run it's own /Out folder for output DLL's
mstest.exe /testcontainer:Tests.web.dll
mstest.exe /testcontainer:Tests.svcs.dll
mstest.exe /testcontainer:Tests.core.dll