I have a vulnerability scanner that returns a finding for an outdated dotNET build - 2.1.17. This needs to be removed.
I have confirmed the file is in the right spot (C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All\2.1.17) and I have deployed the updated version "2.1.25".
Unfortunately, 2.1.17 refuses to be removed - the latest dotnet-core-uninstall tool does not list it as an option, and it doesn't let me just hand-jam 2.1.17 as an -aspnet-runtime option either.
Somewhere on the 'net I found a suggestion that if I remove a certain SDK installation (5xx something - naturally can't find it again) that it would also remove the files. It didn't, and 2.1.17 is still there.
I also tried simply taking ownership of the directory in Windows and then removing it with RMDIR. The directory was removed and all the files were gone, but when I rebooted it looks like it was actually restored and now I'm stuck with 2.1.17 again.
I'm no Developer, so my experience with these packages is in deploying and removing them, which I've done successfully in the past either by deleting the folder (for a very old version) or this dotnet removal tool. I've not had the Runtime simply just not be removable.
Is there a way to get rid of these Runtimes without the dotnet tool?
EDIT: I followed Ian Kemp's advice below and it did briefly remove the 2.1.17 folder that was behind my finding, but it actually restores when the machine is rebooted (causing it to be flagged again).
The solution for me was to remove the 2.1.813 SDK, then manually TAKEOWN and RMDIR the offending directories, then reinstall 2.1.813 SDK.
Related
I can't update any/all of the following packages in my solution:
I get the error:
I've tried reinstalling all packages via NuGet console but still get the same error.
I'm using VS 2022 64bit v 17.0.4. Migrating to PackageReference isn't allowed on this solution.
The only workaround for us was to clone the solution from the remote repository to a fresh local directory.
We tried emptying the NuGet cache, but without success. The problem is that the .dll-File was not present in the package directory (see file path from OP). Mixed backward and forward slashes are not a problem. Deleting/restoring packages did not solve the issue. Commands like Get-Package didn't work either.
We tried diffing the two folders, a) the freshly cloned working one and b) the old not working one, as we suspected that config files not under version control caused the issue. But without any success. We couldn't find any relevant difference. The binary .suo-File was not considered by us. Deleting the .suo-File and restoring packages didn't solve the issue either.
We gave up on that point because we have a workaround to deal with this issue.
I would dig for global VS/NuGet cache/setting files but we decided to not invest more time on that.
By referencing these Nuget Official Site and .Net Standard Implementation Support Chart, .Net 4.6.1 is compatible with NetStandard2.0 Applications.
Please check the version compatibility from the above references and try installing the required dependencies.
I had the same issue and as you wrote that copying repository to fresh local directory worked for you, I made some tests.
I have figured it out, that the problem is windows's path lengt limitation to 260 characters.
Maximum Path Length Limitation
I'm having issues getting some modules to install. I've been able to get mod-1v1-arena and mod-npc-free-professions working, but I haven't been able to get these other modules to work:
mod-new-character-perks
mod-learn-spells
mod-quick-teleport
Can someone please confirm I have the correct workflow, or advise on what steps I'm missing.
Clone module folder from git to .\azerothcore-wotlk\modules
Run Git CLI: ./acore.sh docker build
Copy mod_learnspells.conf to .\azerothcore-wotlk\env\docker\etc\modules
I see instructions about rebuilding with CMake, is that necessary if I'm using docker build...? I tried CMake too and I got an error immediately with the software setup, so haven't pursued it further.
I'm also a bit confused by the .conf files, which folder does the server read them from?
.\azerothcore-wotlk\env\docker\etc\modules or .\azerothcore-wotlk\modules\mod-learn-spells\conf
I would try to install without any modules to check for the core stability and then work up from there one by one.
This way, if there's a module that's currently not working due to recent PR's like the Autobalance and possibly mod-learn-spells you can report an issue and work without it until It's back up.
AzerothCore Continuous Integration build with modules is currently failing aswell if you check the Readme notes where it says
I recently added the new .NET compiler NuGet packages (Microsoft.CodeDom.Providers.DotNetCompilerPlatfor) to an existing older MVC.NET website. Now when trying to publish the website I get the following exception:
Could not find a part of the path …
\obj\DEV\AspnetCompileMerge\Source\bin\roslyn\csc.exe'
I have tried everything mentioned in this question, but nothing worked. It is, after all, a slightly different problem. The problem mentioned in that post is build exceptions, my solution builds fine locally. Uninstalling the NuGet packages works, but that's not really a solution.
The issue is basically the same as this one, but that also has no solution.
Publish output:
4>------ Publish started: Project: Jdn.ArticleCatalogue.Web, Configuration: DEV Any CPU ------
4>Connecting to \\vm-arcawebdev01\WEBSITES\ArticleCatalogue...
4>Transformed Web.config using D:\DOTNET\Local\Logistics.Web\Portal\DEV\Application Projects\Article Catalogue\Jdn.ArticleCatalogue.Web\Web.DEV.config into obj\DEV\TransformWebConfig\transformed\Web.config.
4>Copying all files to temporary location below for package/publish:
4>obj\DEV\AspnetCompileMerge\Source.
4>C:\Windows\Microsoft.NET\Framework\v4.0.30319\aspnet_compiler.exe -v / -p "D:\DOTNET\Local\Logistics.Web\Portal\DEV\Application Projects\Article Catalogue\Jdn.ArticleCatalogue.Web\obj\DEV\AspnetCompileMerge\Source" "D:\DOTNET\Local\Logistics.Web\Portal\DEV\Application Projects\Article Catalogue\Jdn.ArticleCatalogue.Web\obj\DEV\AspnetCompileMerge\TempBuildDir" -keyfile "..\..\..\Solution Items\Jdn.LogisticsPortal.snk"
4>ASPNETCOMPILER(0,0): Error ASPRUNTIME: Could not find a part of the path 'D:\DOTNET\Local\Logistics.Web\Portal\DEV\Application Projects\Article Catalogue\Jdn.ArticleCatalogue.Web\obj\DEV\AspnetCompileMerge\Source\bin\roslyn\csc.exe'.
Any ideas on how to solve this one?
This was a known issue whereby the Roslyn binary wasn't being copied correctly to the publish directory. It should be fixed if you install Microsoft.CodeDom.Providers.DotNetCompilerPlatform 1.0.7.
There seem to be some residual issues which are being tracked here.
Same problem accourred to me while publish MVC .NET application to my local path. I solved the problem delete Microsoft.CodeDom.Providers.DotNetCompilerPlatform by nuget package.
We have a solution file which contains several projects which builds just fine on my computer using both "dotnet" CLI as well as Visual Studio 2017. Literally overnight, the build would fail, and I cannot associate the change that may have attributed to the failure. Both VS2017 and CLI failed with a message like this:
C:\Program Files\dotnet\sdk\1.0.4\NuGet.targets(97,5): error : Failed to retrieve information about 'System.Xml.XmlDocument' from remote source 'D:\mtp\proj.vs\hello_proj\bin\Release\PublishOutput'. [D:\mtp\proj.vs\server-ray\my_solution.sln]
This is is misleading, as the hello_proj where this seems to indicate, is configured for building "Debug" as oppose to the "Release" shown. I have already attempted to clear out all cached packages, copied packages to where the solution resides, and copied the packages to where the error indicates, but I could not get over this error. Nuget is obviously getting some information somewhere to look for the packages in the wrong place, but I don't really know where it gets that info from. I also verified that the "missing" packages exist in the "global-packages" folder (found by running "nuget local all -list").
I found something that fixed my problem; I searched for Nuget.Config in the entire C: drive and found one in %appdata%\Nuget\Nuget.config. I removed it and the build went through successfully. The Nuget.config was restored to some default values that fixed the problem. I can't explain it; just glad it worked.
It looks like that one of your dependencies is pointing to D: which could have been removed by any reason. I suggest you to delete the packages folder, find the dependency that refers to D: and remove and add it again from NuGet. By the end you can let Visual Studio restore all of dependencies.
Fow the last few days I used to work on STS. But today it is not launching and giving following window. So, I reinstalled STS. But the problem still exits. Can some one help in sorting it out?
I found the solution after few hours. Some guy had same problem and solved
here:
Eclipse is trying to get the version of java that is installed on system. you might have installed that latest one but there are possibilities that any upgradation of later softwares has replaced the java.exe files in system32 folder with older version. All you need to do is to run eclipse with clean parameters. Create a batch file in the directory where eclipse.exe is and write this line in it eclipse -clean -vmargs -Xmx256m