I'm getting an error that "The import project '[file path here]' was not found. Confirm that the path in the declaration is correct, and that the file exists on disk."
However, I can confirm that [file path here] is correct and does represent an accurate file that does exist on the disk. Running as administrator does not fix the problem, restarting VS does not fix the problem, and expanding the environmental variables that create the path do not fix the problem.
Edit: The file is on a local disk, not a share, and my account is a local administrator, so there are no possible permissions issues here (especially since running as admin didn't resolve the issue)
Edit2: This only happens with isolated files and is not systemic through all imported projects.
Any suggestions?
You can use Process Monitor from Sysinternals tools to check what paths are actually accessed during the build. This should give you the idea of what is missing. Make sure to filter only for required process and from you description it seems you need only to check file system access. Otherwise you will get a lot of events and it will be much harder to troubleshoot the issue.
It would appear that since there was a conditional on the Identifier i was using allowing others to override it, a different file was overriding it with the same identifier but with a space, removing the conditional fixed the problem.
Key takeaway here, make sure you know who and what are setting your variables.
Related
I am trying to get a C# Visual Studio 2019/MSBuild job to build on a Jenkins build server. I know that my file paths are too long, so I have enabled Long File Paths in the Group Policy Editor (and verified that it has persisted in the registry editor after a server restart).
However, now I am getting the following error "ALINK: fatal error AL1065: File name ... is too long or invalid".
A quick google search led me to this page for Alchemy Software. However I have no idea what Alchemy Software is and why it is being used in the build process and why it is failing. (Although for the last point, I'm guessing that the Alchemy Software .dll is not "Long Address Aware", which I believe is necessary for an application to take advantage of Long Paths in Windows. But since I can't locate any .dll or .exe associated with this software, I can't be certain.)
Does anyone know why my build is still failing with this error, what Alchemy Software is, and how to get it to take advantage of Long Paths in Windows?
P.S. And please, no comments about how I should restructure my file paths to be shorter. I have tried doing that but it's impractical for this application. And anyway, it keeps popping up and is becoming a whack-a-mole situation, so I'd really rather fix the root cause rather than constantly putting band-aids everywhere.
I am going to set this as an answer since, after Hans Passant's very helpful comments and subsequent research, I think it's pretty definitive that this can mostly only be worked around, not resolved. (As possible exception will be discussed at the end of this answer.)
As stated in those comments, this error originates from a linker module called al.exe that is utilized by MSBuild for certain project configurations (more on that later). This linker can be found in a couple places, but for me it was being called from C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.8 Tools.
MSBuild can handle long file paths as long as Windows is configured to do so (by enabling long paths in the Group Policy Editor or by modifying the registry directly). However this al.exe module cannot. And as far as I can tell, there's no way to force it to do so. So if your build tool chain requires this al.exe module to be used, you're kind of SOL.
For my particular situation, for a job in Jenkins that was failing because my paths were too long, I worked around this by changing the workspace of my job. So now instead of the default of something like D:\Jenkins\workspaces\[product]\Releases\[product_version], I changed it to D:\j\dd0_1c, which is an encoding that makes sense to me. This shortening of the folder path avoids any subsequent file paths from exceeding the limit of 260 characters. It's not a satisfying solution, but it works for my particular situation.
I did mention that there was a possible exception to all of this: if you can get MSBuild to avoid using al.exe altogether, then you can avoid this error.
I don't know all of the scenarios or workflows in which MSBuild utilizes this module, but I do know that it does get utilized when your application has localized resources, and somehow, some way, MSBuild uses al.exe when it is generating those resources. This was exactly my scenario, and I found this page and this page describing how you can reconfigure your localization projects such that MSBuild does not utilize al.exe. I did try the steps described in these pages and was able to verify that I no longer got this ALINK error from al.exe. However I never got my project to fully build since this reconfiguration caused other build errors to crop up. So in the end, for the sake of expediency (and because it was cleaner than performing a major refactor of my code), I went with the Jenkins workspace workaround.
However, it is interesting to note that you can get MSBuild to avoid using al.exe as long as your project is conducive to the solution given in those two links. So hopefully, if someone runs into this same issue, they might have more success than I in utilizing this method.
while building xamarin forms android app in debug mode
I am getting following error
Unable to remove directory "obj\Debug\90\android\bin\classes". Could not find a part of the path 'AccessibilityManagerCompat_AccessibilityStateChangeListenerImplementor.class'.
unable to find resolution for this as line number is not shown
Your path to the solution could be too long. I solved this by moving my solution closer to the C drive root. Also take into account that your application might not have sufficient rights to access that location, so make sure you give the necessary access rights.
Manually delete your bin/obj folders from your Solution, and then try to rebuild.
Usually this does the trick, since it is trying to remove a class that he cannot find a path of.
Manually deleting the obj\Debug\90 folder and subsequent build worked for me.
Clean and Rebuild didn't do it for me.
You need to make sure that the path is short and you dont have any spaces or special characters in the path to your project
The latter one was the issue that haunted me for a while.
For example: C:/abc xyz/ProjectName/... is unacceptable because there is a space between abc and xyz.
I don't exactly know why but this works for me
Happy coding!
I am trying to use SDO2SHP.exe in order to export some spatial data from Oracle for use later with shp2pgsql in order to import it to a postgresql database. I receive the error:
"The program can't start because shapelib129.dll is missing from your computer. Try reinstalling the program to fix this problem."
Has anyone come across this problem before? If so what is the solution. The obvious thing would be to download the dll from somewhere however I cannot seem to find it. There is not the option to install the program as it is simply an executable file.
P.S. If anyone could add a custom tag I would appreciate the sdo2shp tag being added. Apparently it hasnt been used before.
The file shapelib129.dll can be found in the following location:
\sdo2shp\Libs\SHAPELIB\Delphi\
This file must then be copied into the same directory as your SDO2Shp.exe executable file in order to allow it to work.
We're finally getting around to moving our software's documents out of the program's own directory and into "My Documents". We're also adding a "requestedPrivileges" line to the manifest to prevent further trouble with virtualization.
However if we only did that then anyone who had been running the old versions in Vista/7 is likely to lose their work somewhere within the hidden VirtualStore directory after updating. So what's the preferred way of migrating into the 21st century?
Frankly I'm a little wary of copying files around, especially as I can't seem to find a programmatic way of getting at the shadow directory, but presumably plenty of other people must have had the same problem before us.
Don't add requestedPrivileges unless you legitimately need administrative rights in order for your program to work - nothing in your description suggests that you do. That should also let you simply copy the files on the first boot as if they were still in your program directory, because any virtualization would still be in effect.
However, if you absolutely must do the migration without UAC enabled, you can find your files in %LOCALAPPDATA%\VirtualStore\path\to\file. For example, if your file would have been stored in C:\Program Files\OurApp\, you'll find it in %LOCALAPPDATA%\VirtualStore\Program Files\OurApp\.
To get the path to %LOCALAPPDATA%, you can use SHGetSpecialFolderPath with CSIDL_LOCAL_APPDATA as the CSIDL parameter.
In my working folder of a VSS project, is it alright if I make all the files/folders writable? i.e. not readonly?
It is ok, but why should you?
The read only state is a safeguard so you can't change code that is not locked. Avoiding possible merge troubles in the near future.
Edit: Ok in the comment you said that the build failed because the file was not writable. If so, then it is very strange. Especially if the error message said something about not able to access the file.
It was probably still locked by another process and changing the readonly flag removed the lock (or it just needed the delay). But as far as I know, compilers do work excelent with read only source files.
Possible problems:
Files on network drives. If the network is slow, the compiler can have trouble accessing the file.
File still open in (an other) editor. Normally this shouldn't be a problem, but you may never know.
Some code files are generated during the build. In this case they don't belong in the version system, their source (if any) does.