enter image description here I need Help, I work on one project and yesterday i have accident and i damage my PC,I did Project backup and Now i try to import Projrct on my lap top, and i folow instructions but i folow some unexpected errors also, is saying that hal drivers is missing, i give propher path address to all folders but still not fixed, old project was worked fine on Win10 english FW1,5,1 i try to import in win 11 German, i download and add FW 1,5,1 but error still exist.
i try older backup version and still same messige. there is no missing files. just some incompatabiliity.
Related
Unity 3d doesnt work, when I try to open my project it says that This can happen if layout contains custom windows and there are compile errors in the project. I tried reinstalling OpenGL and something that I found on the internet but didn't work. The error window says that Revert Factory Settings but same thing happens after it too my Unity version is 2020.1.0a My OS is Ubuntu and I gave all the permissions to some folders. Didn't work And all this happened after a fresh install
Unity 2020.1.0a3 is an ALPHA VERSION!
As any alpha version it is not stable for production and can be expected to be full of bugs and unexpected behavior.
Search through the Known Issues in 2020.1.0a3 maybe your problem is already listed there.
In general do not touch alpha or beta versions unless you want to checkout a new added feature and test it.
For anything else stick to the stable releases like 2019.1.14f1 or 2019.2.6f1
On the last letter you can see their state:
a = Alpha
b = Beta
f = Release
Not sure if these are related but here and here also others had this problem already in early version so maybe one of their hot-fixes work for you as well.
This error may occur in released versions.
To resolve this problem:
Go to this directory:
C:\Users{YOUR_USER}\AppData\Roaming\Unity\Editor-5.x\Preferences\Layouts\default
Open Default.wlt file with Notepad or any text editor and copy all its contents.
Go to your unity project directory like this:
{YOUR_UNITY_PROJECT}\Library
Open CurrentLayout-default.dwlt file with Notepad or any text editor and delete all its contents then paste the contents of Default.wlt that you copied in step 2
If these files exist in Library delete them:
CurrentMaximizeLayout.dwlt
CurrentLayout.dwlt
Stop the Unity Hub service by a click the system tray and right-click on Unity Hub icon then select Quit Unity Hub.
Run your project again.
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.
I'm trying to get VSCode working with my Unity projects, and every time I select the Project icon (the little fire at the bottom) I get the following error:
Error: Failed to connect to OmniSharp
Is anyone else getting this?
You need to download the most recent version of "mono". Open up terminal and pass in brew install mono. Then "Pick a project" and select the ..-csharp.sln file and you should be up and running.
Ok, made some progress and gotten a few Unity projects working. It seems that you need some prerequisites installed, a clean up of your Unity project folder, and possibly some hand editing of your .sln and .csproj files.
I posted a (possibly) better answer over on Reddit. Hope that's not breaking stack etiquitte.
http://www.reddit.com/r/Unity3D/comments/34d6gc/visual_studio_for_mac_help_us_vote_for_unity/
i get this on windows when my project directory has a space in it
i removed the space and removed the error
i expect it will be fixed soom
I have a completely different answer: it's the runtime that VSCode is using. It doesn't match up with what it thinks it needs. I have to remember that we're still in beta and that things are changing rapidly. I had my dnvm running beta 7, but VSCode (and OmniSharp, by extension) is looking for beta 6, so it was failing. I updated my runtime using this this post as a clue. Now I have VSCode 0.7.0 using the beta 6 runtime. I have no idea how to tell what it's looking for...I just guessed based on when they were both released. HTH
I want to get rid of this error message and I want to have the benefits of auto completion and suggestions. PyDev obviously does find nltk, because when running it from inside the IDE it works. Not only from console.
Surely someone needs to know why I got this "unresolved import" error message but on the other way when clicking on "run" it works perfectly well.
#TheGT seems to be on the correct path, though I found the instructions a little confusing. My solution:
Project->Properties->PYDEV-PYTHONPATH->External Libraries
Add source folder (button)
/Library/Python/2.7/site-packages/nltk-2-0/4-py2.7.egg
Obviously, your path, version, etc... could be different.
Here's what seems odd.
There's a button to add zip/jar/egg and that doesn't want to work correctly with the nltk...directory...egg. The nltk egg behaves like a directory in the chooser (i.e. continues to drill down rather than return).
On the other hand, the source folder button does allow you to choose a folder... so I chose the egg and that seems to work.
It seems like the nltk egg is not configured correctly for OSX. And, depending on how it is accessed, it can behave like a folder or a final destination.
NOTE: Adding the nltk egg into the external libraries path of your project makes the error go away. But adding the egg into preferences>PyDev>Interpreter does not appear to resolve the problem (on it's own).
I faced the exact same error when I was trying to use nltk in my project. I did 2 things to resolve the unresolved error to go away.
I added the setupctools**.egg file (the file that is used to install nltk in mac/*nix systems) as an external library
[Project->Properties->PYDEV-PYTHONPATH->External Libraries]
I am using Eclipse Indigo, and Python 2.6.1 on my mac btw.
I restarted the eclipse
Bam! - the error goes away.
Although, the error is not there anymore, I would like to know why Eclipse was behaving this way. The strange thing to note was that when I tried to run the program, the program did run successfully, even though eclipse marked "import nltk" as unresolved import.
I've been using Flash Builder 4.5 with Flex SDK 3.5B on Mac OS X 10.8.2 for a couple months. It hasn't been a perfect experience—the software has quite a few bugs—but in general it has been working until recently.
Our application includes two Flash Builder "projects", one of which references the other. Whenever we clone the repository, it is necessary to update the .project file of the primary project to include the new path of the secondary project.
The last thing I did before everything broke was move the folder containing the projects to a new location. As expected, when I opened Flash Builder, it complained that it couldn't find my project files, and they were all marked as inaccessible in the "Package Explorer" view. I did not remove the inaccessible projects from my workspace, but I attempted to re-import the primary project from its new location. This marked the first time I saw a dialog that has haunted me ever since:
The "Problems" view told me to refer to the error log...
...but the error log was empty!
The "Package Explorer" view didn't change (the new project wasn't listed) so I decided to just try the import again. When I selected the project directory, Flash Builder said I couldn't import it because the project was already in the workspace. "But the Package Explorer says it isn't... maybe it'll let me try again if I restart Flash Builder," I thought. I thought wrong. When I restarted, this is what I saw:
java.lang.NullPointerException
at com.adobe.flexbuilder.util.PathUtils.resolveLocaleInSourcePath(PathUtils.java:297)
at com.adobe.flexbuilder.project.actionscript.internal.ActionScriptProject.getProjectPath(ActionScriptProject.java:713)
at com.adobe.flexbuilder.project.actionscript.internal.ActionScriptProject.getSourceContainers(ActionScriptProject.java:681)
at com.adobe.flexbuilder.as.editor.ui.packageexplorer.content.FlexPackageExplorerContentManager.getSourceRoot(FlexPackageExplorerContentManager.java:644)
at com.adobe.flexbuilder.as.editor.ui.packageexplorer.FlexPackageExplorerContentProvider.getWorkspaceRootChildren(FlexPackageExplorerContentProvider.java:152)
at com.adobe.flexbuilder.as.editor.ui.packageexplorer.FlexPackageExplorerContentProvider.getChildren(FlexPackageExplorerContentProvider.java:80)
at com.adobe.flexbuilder.as.editor.ui.packageexplorer.FlexPackageExplorerContentProvider.inputChanged(FlexPackageExplorerContentProvider.java:449)
[...]
It couldn't even display the list of projects so I could remove the one that was causing the issue. A similar message was displayed in the "Editor" view. Deleting all of the project's files didn't help either. I was unable to fix the workspace, and the only way I could continue to use Flash Builder was by creating a new workspace.
Since then, I have tried many different things:
Reinstalled Flash Builder 4.5.
Reinstalled Flex SDK 3.5B.
Checked out a six-month-old version of the project.
Upgraded to Flash Builder 4.6.
Created a new user profile on my computer.
Tried to remove whatever trace files might have broken things:
Used Instruments to monitor all files the Flash Builder process touches.
Uninstalled Flash Builder.
Used find to locate any files that included builder or eclipse in their name.
Deleted all files found in (1) or (3) that seemed possibly related to Flash Builder.
Reinstalled Flash Builder.
Installed Flash Builder 4.5 on another Mac running Mac OS X 10.6.8.
Checked out a two-year-old version of the project with Flex SDK 3.5 on the other Mac.
Tried in a new workspace on another Mac that already had the project working in an existing workspace. (Yes, it broke when we tried to import it into the new workspace, even though it continues to work fine in the existing workspace.)
Installed Flash Builder 4.5 in a Windows 7 VM.
None have made any difference. That seems impossible.
Other members of my team have been working on this project for a couple years without running into this particular issue, yet now versions of the project from before I started appear to be broken, and even using brand new installations of Flash Builder on entirely different systems also breaks.
I contacted Adobe's phone support for help with this issue. I waited on hold for over an hour after being told it would be fifteen minutes, only to have them tell me that they no longer offer phone support for the product. (Sadly, their phone tree couldn't figure that out before I waited on hold.) However, I was told that "tier 2 email support" was available at platformt2-noida#adobe.com. I should have known better than to get my hopes up the address was invalid and my messages all bounced!
I have no idea what's going on. It seems like I must have done something else and forgotten about it, because the current situation makes no sense. Has anybody encountered this issue before? Do you have any idea what might be causing it, or what I might do to fix it?
We finally found a solution. It's rather anticlimactic.
Ignore all of the errors.
Import your project files and activate the correct SDK version in whatever order you want. If you end up with a messed up "Project Explorer" view, just close the view and reopen it, or restart Flash Builder.
Once the "Project Explorer" view is available, select your primary project and run it. It should work!
Nothing was actually permanently broken. The "Project Explorer" view may be in a temporarily unusable state if you import the primary project first, or use the wrong SDK version, but as long as you eventually fix those things then the "Project Explorer" view will also be fixed the next time it's opened.
make a backup copy of all the projects in your workspace, then delete all the files (including the hidden ones) in your workspace.
Next point Flashbuilder at the now empty workspace directory (forces it to recreate all the workspace files).
now import the project folders that you had backed up.