I can't pull GridGain binaries from Maven repository, since Avast AV blocks GridUtils class as suspected "Agent-CWF" trojan. Tried all 6.* versions with the same result. I'm hesitant to ignore it without confirmation that there is nothing wrong with it and it will also create problems across organization since other team members would probably run into the same problem. Anybody else ran into this? Running Avast 10.2 on OS X 10.10.1.
I reproduced the same issue. This is innocent and can be ignored. The fact that some bytes in GridUtils class match some trojan sequence is a pure coincidence.
Related
I've searched Apple's documentation, open source projects, and Google, and I cannot seem to find any information about SwiftPM.SPMRepositoryError error 5. Heck, I can't even find information about SwiftPM.SPMRepositoryError.
Does anyone know of documentation for this error or the error codes?
What worked for me was switching to ED25519 key.
I think this is happening now because of the effort to improve Git protocol security on GitHub. You can read more about it here: https://github.blog/2021-09-01-improving-git-protocol-security-github/
There you can see the timeline. The final step was put into motion on Mar 15, 2022 (coincidentally that was just two days before your question)
Changes made permanent.
We’ll permanently stop accepting DSA keys. RSA keys uploaded after the cut-off point above will work only with SHA-2 signatures (but again, RSA keys uploaded before this date will continue to work with SHA-1). The deprecated MACs, ciphers, and unencrypted Git protocol will be permanently disabled.
This helped in my case:
File -> Packages -> Reset Package Caches
File -> Packages -> Update to Latest Package Versions
This happened to me on Xcode 13.3 and 13.3.1 when my team added package dependencies that I didn't have Github access to. The error message is ambiguous and shows the same number of errors as the number of packages I have in my dependency tree. But, obtaining access to any repos that I didn't already have access to (which was a smaller number of repos than the error count) resolved the error for me.
I was able to track down the issue by attempting to add another package (anything public like swift-algorithms). Xcode gave me better error reporting in that process.
Updating swift-tools-version in Package.swift file worked for me. We've previously been using 5.3, and updating it to 5.5 or 5.6 resolved the problem.
One thing to keep in mind, Apple has deprecated the existing package declaration functions in Swift 5.6 [1], so using this version would result in a lot of new warnings.
Hopefully, this is just a temporary thing, and a proper fix is coming in the next Xcode version.
Just had the same issue.. (project based on a Package.swift file, not a regular .xcodeproj)
Doubted that it would have to do something with GitHub's policy as described above, since I've worked on other projects today without any issues.
Tried to clear the derived data folder, as well as the project's .swiftpm folder and even the swiftpm repo cache.. nothing helped.
Tried the same project on another MacBook and worked fine!
Then made a fresh clone of the project in a different folder on the Mac with the issue and worked fine as well.
So finally I just deleted the local Package.resolved file, reopened the project in Xcode and everything was back to normal 👍🏻
This seems to be the same issue as Error while fetching remote repositorygit#github.com:***/***.git: An unknown error occurred. reference 'refs/remotes/origin/master' not found (-1) in Xcode 14.
Here is a small script I made to work around it: https://stackoverflow.com/a/74130700/624854.
I'm getting the following error when attempting to install a nuget package into a standard .NET framework 4.7 project:
The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters.
I'm using Visual Studio 2017 15.3.3 Enterprise (latest and greatest).
Given that this is my package, I have full control over the source code. The interesting part is that I have used this package in the past with no changes in the name, but for this go round, I rebuilt it to add a feature and am now getting this error.
Even more interesting is that I have packages from the same library, with the same namespace conventions, with longer names, that work just fine and have installed into this same project with no problems at all.
I have already tried shrinking the package name, shrinking the class names within the package itself, cleaning out the build directory, cleaning out the package home from the nuget server (it's a local server with the latest nuget.server installed which otherwise works just fine), and even clearing out the bin directory of the project in question, clearing out ALL the bin directories of ALL the ancestors to the "offending" package, clearing out the package cache, rebooting the computer and rebuilding the entire nuget package chain from scratch, all to no avail. I was told by one of the MS MVP's that "they fixed that". Apparently not.
Any help would be appreciated here, I'm at my wit's end and have run out of ideas to try.
Thanks.
OK, big Thank You #danmosemsft who suggested digging around with the SysInternals process monitor. After fiddling with it for a bit, I finally figured out how to narrow the result set to just file activity. What I noticed, and the nuget engineers should TAKE NOTE of this: The problem was NOT a too-long project name, rather, nuget was attempting to update a package that was no longer there. Why it went away is a mystery yet to be solved. I normally stay out of the packages directory and do not fuss with the packages.config file. I think that this might have to do with my impatience waiting for VS to start, load all the goodies and then allow me to perform a "Manage NuGet packages" - update all. I remember seeing an update to either NUnit or FluentAssertions that wanted to perform some additional file activity aside from just installing the next version, a script I believe. Can't speak to it with assurance, I wasn't paying that much attention as third party updates usually "just work". I didn't see the "finished" line from NuGet so I think that was the root of my problem. Rather than wait until VS has settled down, I pushed it a bit (hey, the buttons responded so there shouldn't be any problems...).
As a result, the packages directory was absolutely chock full of old stuff that did NOT belong there. So, I manually cleaned up all the cruft, manually cleaned up the packages.config file, restarted VS, waited for it to settle down, performed my NuGet updates and viola! no problem - HAVING NOT CHANGED ANY OF THE ANCESTRAL PACKAGE NAMES BY EVEN A SINGLE CHARACTER.
So, what do I conclude from this? It is my belief, and the guys that actually build nuget and nuget.server should take a closer look at the errors being thrown, such that I think that the error is not so much a path too long error, rather it's a "hey, I didn't find the file I expected so the file name is full of junk (and probably too long now) so I'll throw an error that says it's too long and quit". It's seemingly a failure to handle a missing package/package directory that is causing this particular problem
I solved my problem by ensuring that all the package directories were clean of all junk and rebuilding from a clean source. My problem is now solved.
Thanks to all of you that responded.
Update: While the above contributed to the solution, it was NOT the answer. Here is the sequence of events that led to this problem and it's ultimate resolution.
The solution was created in the C:\User\Sam\Documents\Visual Studio 2017\Projects directory with the specified name of AWE.Lib.ADO.MsSqlSvr.ServerEntityHandler. This worked just fine, no errors. However due to a change in naming scheme from on high, the root directory for this project was changed from "C:\User\Sam\Documents\Visual Studio 2017\Projects" to "C:\User\Sam\Documents\Visual Studio 2017\Projects\DotNet_4.7\AWE 8.x". No problem, I thought - given that a co-worker who also happens to be a MS MVP had told me that all naming length restrictions had been removed in VS 2017. So...I moved the project from it's current home to the directory specified. Compiles just fine, brings in UPDATED BUT ALREADY INSTALLED nuget packages just fine, etc.
Or so I thought. When I needed to add a NEW (one that had not been a part of the solution before) nuget package to the mix, I received the above error. Turns out that the new name of the receiving solution is a few characters longer than VS will accept - the naming length restrictions are STILL IN PLACE.
How did I finally solve the problem: After struggling with this, I threw my hands up and decided to start all over again - a true File | New. So, I started with a new solution named as follows:
"C:\Users\Sam\Documents\Visual Studio 2017\Projects\DotNet_4.7\AWE 8.x\AWE.Lib.ADO.MsSqlSvr.HndlrServerEntity"
THIS GENERATES AN ERROR - name too long. I wondered at Nuget's error in that it specifies that the name should be less than 248 characters in length or 260 maximum.
What I am allowed to use iaw the new solution dialog is this: "C:\Users\Sam\Documents\Visual Studio 2017\Projects\DotNet_4.7\AWE 8.x\AWE.Lib.ADO.MsSqlSvr.HndlrServerEnt", for a total of 106 characters in length. If the directory is shortened, I can add to the length of the name. If I shorten the length of the actual solution name, again, VS'll accept it. So long as the total length of directory plus solution name is less than or equal to 106 characters, there isn't a problem.
The nasty bit comes from creating the solution in one location and having it work in all respects just fine, moving said solution to a different directory, still having it function in all respects (I did NOT need to add any new nuget packages yet), then trying to add a new nuget package to the mix after the move. THAT is what triggered the above nuget error.
So...the ultimate "fix", use a shorter name as it seems that 106 characters is the limit despite what the error messages are saying (and what the MS MVP was told/told me).
There is another reason for this error message by the compiler.
While building , make sure the source code is placed at a folder location which is less than 260 characters long.
For example, a path like C:\Users\User\source\Services\Exp\Sample-web-application-indot-net-displaying-RestAPI\Sample-web-application-indot-net-displaying-RestAPI\SportsStore is around 150 characters long but there are sub folders in the solution which in turn have source code files and so on.
Sometimes the overall length of the path of some files breaches the 260 character length.
I think the future versions of Visual Studio would have a bigger length allowance. Until then, we can make sure that our file names are not too long.
I was running into the same issue after I moved a project to another folder. In my case I closed VS renamed the .vs folder in root to 1.vs (effectively removing it) and re-opend my project.
In my case, I was first trying to install a package using Manage Nuget Packages for Solutions and was getting this error. Then I tried installing same package using Package Manager Console and it worked fine. I again uninstalled that package and tried installing using Manage Nuget Packages for Solutions and this time it worked fine as well.
Well in my experience all i had to do is move the entire project to my c: drive, delete unnecessary folders to ensure the path would be shorter. Done deal.
This error comes to me when I tried to copy the project folder to OneDrive and the problem is that OneDrive is not uploading long name files.
I've fixed this issue by just copying the project folder then paste it in the new laptop using USB.
I wish this could help
Move the folder of the project to a folder within a few levels from the root dir. For example the Desktop and voila.
Try to close Solution from File->Close Solution and opening it again.
For my case uninstalling, installing, or even updating NuGet packages, nothing was working but reopening(sometimes you can also close and open Visual Studio again) the Solution did the magic.
New to Android. I'm trying to build the HelloCompute sample code for API 17 with ADT v22.0.1 under Windows 7. I do File:New Project:Android Sample Project, and select HelloCompute. In the Package Explorer I see HelloCompute.java and mono.rs in src under com.example.android.rs.hellocompute. However, I don't see any reflected layer code under gen, and I get the error "ScriptC_mono cannot be resolved to a type". I have tried re-installing eclipse / adt, and re-installing the sample code.
Is there some manual step I need to perform to generate the reflected layer?
Thanks.
I ran into a similar problem.
I got around it by running llvm-rs-cc on mono.rs and generating the ScriptC_mono.java file. Eclipse then picks up this source and compiles everything successfully.
I do not know yet whether is there a way of telling eclipse to do it automatically.
The latest ADT does have a problem in generating RenderScript code as part of the build process, so you need to do this step manually right now (or look at other threads suggesting workarounds). Hopefully the upcoming ADT will actually fix this issue so that everything gets created automatically.
Had the same problem.
Win 7 64bit.
Eclipse 4.2.2.
Upgraded to:
SDK Tools: 22.0.5.
Platform-tools: 18.0.1.
Build-tols: 18.0.1.
Problem solved.
Renderscript compilation was broken in ADT 22.0.1. Fixed for non-Windows platforms on 22.0.4. Fixed for Windows platform on 22.0.5.
I searched lot about this topics but can't find a proper solution.
I am using eclipse 3.6 Helios version with operating system fedora15. In my application I am using GWT2.4 for front end development.
Now while I work with debug mode and want to debug at some point at the same time eclipse hangs for 3-4 mins.It resumes after and again start to debug process.
I am using this eclipse from last 3 years with windows but not faced this issue.In fedora I am using it from last 4 months and this problems stated to occur from last one month.
I am not getting what is the issues with eclipse.
Please help me out.
Thanks in advance.
Is this something that happens with different projects/code, or is it the same code that causes freezes? I've had issues where threads have started in the background and caused problems.
You say "(...) hangs for 3-4 mins.It resumes after and again start to debug process.", what do you mean? Does it continue to debug and move to the next line, or is there a crash and it restarts?
How long has it been since you changed workspace? I've found this, rather than the Eclipse installation, to be an issue over time. Create a new workspace folder, export all your projects and preferences and start fresh.
You are using GWT 2.4 and I think you might be working with UI.xml too... There is a tag in each ui.xml at the top like
<!DOCTYPE ui:UiBinder SYSTEM "http://dl.google.com/gwt/DTD/xhtml.ent">
Which means eclipse is going to get that xhtml.ent file each time and there is a issue in GWT eclipse plugin have a look to below link
http://code.google.com/p/google-web-toolkit/issues/detail?id=5265
There is one comment which says
For me, removing
SYSTEM "http://dl.google.com/gwt/DTD/xhtml.ent"
and saving the document,
solves the problem..
maybe it is needed for something, so better you copy that locally somewhere, and link that.
Try it out and let me know.
I had experienced the exact same problem on a less-powerful notebook I had to use.
Try one of the following
Download the latest Eclipse version (It needs, just as helios, a lot of RAM and CPU because it's based on a new "architekture", in contrast to, for instance, galileo)
Make sure you are using the latest JDK and JRE
Download Eclipse Galileo, which does require pretty less resources and goes still very very fine with most projects!
It sounds like you are experiencing the features of the latest Eclipse arch. In the latest versions of Eclipse I have noticed that the more plugins and add-ons you have installed, the slower the environment runs. There are a lot of similar posts regarding performance on the new platform
I have removed all but the plugins I am using and never install anything not needed into the Eclipse environment.
I "may" have experience this. Not sure. Suddenly started working again. I was getting a hang every time I would try to debug an app, in the part of the code (inside GWT) that creates a "table" element. Could be that there is something that just takes a while and you just have to "wait it out" the when it happens. Go get a cup of coffee, type thing. anyway I HAD stepped deep into the GWT code, plenty so I'm convinced it IS a GWT issue of some kind.
I was thinking it was some infinite recursion possibly in the logging system (like logger code accidentally trying to log itself, and going into loop?). Also there's a 50/50 chance that it was simply clicking on 'run' instead of 'debug' made it start working again. So at least try that if you have problems. My gut instinct and 30yrs programming under my belt tells me it's logger related. I can rule out "slow computers" because I never had this happen until I got a new machien which is Dell XPS, Core i7, 8 GB ram, and massive disk. So I wouldn't blame hardware, or Eclipse bloat.
I'm running Windows Server 2008 with a Blackmagic Decklink card. Everything works fine with the GUI but when I try to start from command line it exits with an unknown error.
Any ideas?
Note: I have the desktop experience enabled.
Looks like a frequent problem that effects many FMLE users. Common suggestions include:
use the absolute latest version of FMLE
update DirectX
update all video and audio-related drivers
remove/rename startup.xml from "[volume]/Users/[user name]/AppData/Roaming/Adobe/Flash Media Live Encoder [version]/" so the program can get clean settings
There is also a small chance that tweaks to common security measures may help, such as disabling Data Execution Protection for all but essential OS files or exclude program directories in your anti-virus software (only if essential, of course!)
I found out what the problem was, apparently if the fmesessions.dat (C:\ProgramData\Adobe\Flash Media Live Encoder 3.2) gets large enough FMLEcmd.exe fails.