I find increasingly now when I am building a large project, I get the following error.
fatal error C1083: Cannot open
compiler intermediate file:
'C:\Temp\SYS\a03132ex': Permission
denied
It occurs in Visual Studio 2003 and VC6, and I have investigated the potential MSDN reasons and drawn a blank. There is plenty of space on the hard disk, and not that many other programs open that I should be running out of handles. Any ideas, or is it time to re-install windows again. I'm running XP SP3 by the way, and have two large NTFS hard disks with very many files.
Edit: the name of the temp file changes, and I have cleared out the entire c:\temp folder.
I seem to remember from somewhere deep down memory lane that deleting the temporary files created by visual studio for the project fixes this issue (until it pops up again).
The temporary files have the same name as your project. (There may also be something VC/VS related in your home directory if that does not help.)
And if that doesn't help, check if your TMP environment setting doesn't end with a semicolon for example. It should be a fully qualified path as well, not relative.
Edit: I found a topic on the internet about it and there it is said that if you attempt to include a directory instead of a file you can trigger that very same error.
I assume you already verified this, but does the actual C:\Temp\SYS folder have the correct permissions (ie allow all users to read/write files in it)?
You could also check the rights associated with c:\temp and c:\temp\sys (if sys does exist outside the compilation session)
cacls c:\temp
Also, (as suggested here), try setting the compiler flag -Bd under advanced options and inspect the arguments into the compiler. Maybe you meant to specify a path and end up compiling a non-existant file ?
Keep your temp file location simple, for example when I copy projects from my laptop to my office PC the VS2003 project didn’t compile.. The “tmp” system variable was pointing to %USERPROFILE%/TEMP. Visual studio 2003 was giving few "Fatal error C1083: Cannot open compiler intermediate file:" errors
I made a new Temp folder on C drive and change the system variable TMP to "C:/TEMP". Recompiled the program and Voilà no errors!
do not click Rebuild button in complier, click Build button only - this solve my problem
I had exactly the same issue. Disabling the antivirus while building the project solved that issue. A possible permanent solution would be to setting VS's temporary directory somewhere else and telling the antivirus to exclude that directory.
Related
What does this error mean:
Error 8 error FTK1013: could not find unicode byte order marker in the file
tracking log file: c:\Users\ASUS\documents\visual studio
2010\Projects\project\project\Debug\CL.write.1.tlog.
The tracking data is invalid. c:\Users\ASUS\documents\visual studio
2010\Projects\project\project\FileTracker project
.tlog files are created as the build goes, writing dependencies, command lines, etc, not anything directly in your control. You're not supposed to see that kind of error unless maybe your disk is full or you manage to launch multiple builds on the same project somehow.
Exit VS, delete the debug folder. Look around in task manager for stray processes or reboot.
Reopen the solution and try build, with some hope the problem just goes away for good.
If someone faced mentioned error you should know that it's VS2010 issue only.
It's already tested and checked. Be careful with following project names:
mt, link, midle, cl, bscmake, rc
In most cases you could just build your project again and buld process will be finished successfully, but if you want to avoid of this error at each RE-build(or first buid, or automatic build by some of control system) you have to rename your project.
Also described and discussed in:
MS Social thread "Error FTK1013: could not find unicode byte order marker in file tracking log file"
Delete the Debug folder in the Visual Studio project folder. Re-build.
I am sharing one workaround for this issue.
Disable /MP for the project(s). Set value "NO" in the "Multi-processor Compilation" setting under Configuration Properties > C/C++->general in the project property window. It worked for me.
Follow these 4 simple steps:
1) go in the Debug folder.
2) Search for the file.
3) Delete the file.
4) Build the project again.
After automatically upgrading the project file for a .Net 4.0 web application to work with Visual Studio 2012 everything worked ok at first however when compiling I got lots of errors like this:
Description : Source File '..\..\..\..\..\File Path' could not be found
File : CSC
And when trying to build using MSBuild (passing just the project full path, with no additional parameters) in the "Developer Command Prompt for VS2012" I got basically the same errors:
"CSC : error CS2001: Source File 'x' could not be found"
All errors refer to Linked Files (aspx,cs,etc) located in other web applications projects located at a different deep in our code Branch (that's why all the '....\' at the beginning of the paths)
To me it looks like a problem with the file Length, I had the same problem a while ago when building the projects on our CI server using MSBuild, I was able to manage it by manipulating the project files before building them using a custom script without the need to move the branch around or reduce the deep of the projects, I didn't have to move anything, the important thing at the time it was that developers using Visual Studio 2010 could compile everything without problems. I learned by this that compiling/Building with MSBuild was different that with DevEnv/VS, and for example MSBuild didn't support building Setup projects and DevEnv did.
Since this is happening now with VS 2012/DevEnv 2012 , plus that VS 2012 doesn't support setup projects anymore (like msbuild), plus VS/DevEnv have the same problem with the file length, it looks like VS 2012 its finally using msbuild under the hood or are more tightly integrated, however I didn't find any article to confirm this.
Changing the branch structure/changing the deep of the projects it’s not an option right now due to several reasons (large code base, high number of projects, risk, timing, effort, etc.).
Does someone have an alternative solution or a fix for this issue in Visual Studio 2012?
Regards,
P.D.: BTW I already checked this post MSBuild error with linked files but like I said before changing the paths its not an option right now.
Try getting the Build Logs,
http://msdn.microsoft.com/en-us/library/vstudio/ms171470.aspx
it seems that csc task could not find the source file. One cause it you import the wrong file.
so you have to edit the project file via normal Text Editor.
I found a solution to this issue, when you linked the file, you relative path is recognized by msbuild and go back from there it become your path in a long path however you can change it in the project definition doing right click/unload the project/ and change the path from ../../../ to $(SolutionDir)/../.. until find the file to link, note: it's extend the character from 255 to 300 character.
Check that you have the latest version of the linked files from the other projects. Visual Studio will NOT automatically get them if they belong to another project.
Check that the linked paths are indeed correct. You can monitor what files VS.NET and MSBUILD are trying to access with the help of the SysInternals ProcMon tool (filter on process names and filter out all successes)
If you suspect that the path length is the problem (this will also be visible in the ProcMon tool), you can try to shorten them by linking to the absolute path (C:\X\Y\Z) instead of a relative path (......\Z). The location of the linked files can then remain unchanged.
My 2 cents to this problem... In my case, I had a file created in one project (i.e. ConfigModel) and I had a link to this file in another project but when I renamed the file ConfigModel in the first project to LoginModel for example, it didn't rename the link in the second project causing this error to occur.
I know that i did this question a while ago but for what is worth, The approach that we finally went for was:
Locating the files that were reported as too long.
Reduce the full path length of those files, by reducing the length of the name and/or
the length of the container folder or reducing the folder nesting
level. Therefore reducing the full path length.
Update the links of the changed files (re-linking) on the dependant projects.
This solved the problem with Visual Studio 2012 on developers workstations and on our CI/Deploy servers that used MSbuild.
For my scenario this approach was less risky,and implied less effort than moving complete projects/solutions to reduce their folder nesting level or reducing the folder names, and have to update all the references of the dependant project/solutions.
Ok, I hit this and solved it today. I found it by following a msdn tutorial (https://msdn.microsoft.com/en-us/library/ms379563%28v=vs.80%29.aspx) and here's the command that broke for me:
csc /t:library /out:MyCodeLibrary.dll simpleType.cs
Giving me the message
error CS2001: Source file 't:librabry' could not be found
Which worked after changing the original command to the following:
csc /target:library /out:MyCodeLibrary.dll simpleType.cs
I'm not sure why the short version of the /target flag causes this error, but I've not found anywhere else online noting this cause specifically so I wanted to record it here.
This problem arose for me when I reverted to an earlier version of a git repository. Apparently I didn't add the project file to the repo so when it reverted it didn't revert the project file also. What I did to clear it up was to exclude the missing .cs file from the project by clicking on the missing file in the project Explorer. It was easy to find since it was marked with a warning triangle. Then rebuild the entire solution.
Verify whether the files mentioned in the error do not exist in the corresponding folder.
If their non-existence is intentional, edit the .csproj files and remove the reference for those files.
Build again.
I inherited this issue from a project somebody else was working on, in my case was a .cs file supposed to be generated by an Entity Framework .tt template, but for some reason it wasn't, so the compiler was going all CS2001 about that. I had to update the template and manually run it, everything worked after that.
I am developing a SharePoint 2013 solution using VS 2012, the solution has a licx file. I get a compile time error and a warning.
Error: The specified task executable "LC.exe" could not be run. The filename or extension is too long
Warning: The command-line for the "LC" task is too long. Command-lines longer than 32000 characters are likely to fail. Try reducing the length of the command-line by breaking down the call to "LC" into multiple calls with fewer parameters per call.
I have tried the lc.exe.config has <startup useLegacyV2RuntimeActivationPolicy="true">
I also tried moving the solution to "C:\", was earlier in the Projects folder.
I am still unable to resolve this error.
There is MS Support workaround:
when you build the project , delete the Licence file from the project
everytime you get this error , just delete the licence file
https://connect.microsoft.com/VisualStudio/feedback/details/779433/lc-exe-task-command-line-too-long
You will be able to save a lot on the path length by making a shortcut to the specific .NET version you use (in this case 4.5.2). Here are the steps;
run command line as Administator
Go to C:\ in command line
mklink /J net452 "C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5.2"
Go to VisualStudio
Open project properties
Look into References tab
Click on "Reference paths" button and add path "C:\net452"
Rebuild project
Deleting licenses.licx file is not a solution. It will give you error at runtime if you are using third party control which need licenses.
LC.exe takes argument as licenses file with full path, if argument is too long, it throw error.
So keep the file name and path shorter length, it will compile and work.
Deleting licence file did not help me. I end up deleting the "licenses.licx" under the Solution Explorer -> Properties group
Surly that helps
This issue is fixed in VS2017 as per this GitHub checkin: https://github.com/Microsoft/msbuild/commit/e49717c727c3cab4db466bcb0a5abb624a8156bb
I believe the version is full release version is VS2017 Update 2.
For no reason that I can see, I can no longer run a TortoiseSVN Update on a development directory on my portable Windows XP Professional SP3 machine, getting the error:
Previous operation has not finished; run 'cleanup' if it was interrupted
Please execute the 'Cleanup' command.
If I try running cleanup, I get another error,
cannot process the following paths: cannot move $ROOT_DIR/.svn/tmp/tmp-... to $ROOT_DIR/path/where/thing/should/go: no such file or directory
I have verified that both files exist, and actually from CMD.EXE prompt I am able to issue a MOVE with those two filenames and have it work correctly. It's no use because next time SVN tries to repeat the operation itself after creating a different tmp file name, and while CMD succeeded, SVN fails.
UPDATE: the path lengths are in both cases well below PATH_MAX, target file system is NTFS, and permissions are OK. Maybe I'll now try with FileMon to see whatever TortoiseSVN is really up to.
I tried downgrading TortoiseSVN but to no avail. Other repositories work OK between the same machines.
TortoiseSVN 1.7.9, Build 23248 - 32 Bit , 2012/08/30 18:25:37
Subversion 1.7.6,
apr 1.4.6
apr-utils 1.3.12
neon 0.29.6
OpenSSL 1.0.1c 10 May 2012
zlib 1.2.7
Both server (OpenSuSE Linux 12.2) and client now run the latest version of SVN.
On Windows, I also cannot seem to get any more informative logs or information (I'm not very skilled with TortoiseSVN, I have always used the Linux command line version).
I might delete the local copy and run a checkout, but it's about 2 GB of data, and I'm on a slow connection, so it is really more of a "fly physically to server location and hook a copper Ethernet to the local network there" alternative. I'm reserving that as a sort of last ditch, nuclear option; I'd really rather understand what the problem is, for I fear it might happen again.
UPDATE
I've tried to delete remotely the subdirectory involved, committing the deletion on the server; deleting the subdirectory locally, and emptying the .svn/tmp subdirectory where I found sixteen tmp files, all copies of the one PNG causing problems.
I am still not able to perform any SVN subcommand, getting "Run cleanup!" error; on cleanup; I get a failed attempt to copy a tmpfile to the never-sufficiently-damned .PNG file, which no longer exists anywhere, into a directory that no longer exists anywhere.
I tried recreating the directory locally (but not the file!), no changes.
With FileMon, I traced the source PNG to 8e4c2389cf9d85c8b8ee54d49ea053c752a38187.svn-base in .svn/pristine subdirectory, tried removing it and got SVN complaining. I tried copying it to its intended destination (so that the file-as-it-should-be and the file-as-it-is are identical), no joy.
UPDATE
Well, this is weird. I decided to track everything that TortoiseSVN is doing using FileMon. I could see it checking the wc.db and search the item, checking for it in .svn/pristine (and finding it), copying it (unnecessarily if you ask me...) in .svn/tmp, and finally checking $DESTINATION_FILE (with correct case) using Windows Open() API. And getting PATH NOT FOUND. Yet the file is there, I can see it (and the name is less than 8.3 characters). And why PATH not found and not FILE not found?
Okay, it all boiled down to a directory that had been created remotely with a name ending with space. The file in itself was OK; the directory where it stood was not.
When updating, apparently, the directory got created but the name was shortened by Windows to exclude the final space.
To add to the difficulty of diagnosing, while TortoiseSVN did tell me what the problem was, it did so in the dialog box where the Arial font made the space in \path\to\your \file not clearly recognizable (it was, once I knew where to look, and compared that slash with the others. This one stood a little farther from the letter at its left).
Lesson learned: check really carefully the dialog file name, character by character (note to self: find a way of having it in Courier New if at all possible).
You may have two files in the repository that differ only in case. That's a problem on Windows. See this FAQ for details.
I'm having trouble using macros in my .inf file that I'm using to create my cab, specifically when setting the InstallDir string. If I do something like this:
InstallDir=\<PathToProgramFiles>\MyAppName
then everything works fine. However, if I do this:
InstallDir=%CE1%\MyAppName
then I get the following error when trying to install the cab (double tapping it on my device): "MyAppName was not installed successfully. Please run Setup again."
This only seems to apply to the built-in macro strings. I can use %AppName% without any problems. Maybe there is some registry setting that isn't properly set that would normally resolve the %CE1% macro?
Any ideas about what is going on?
Edit: My device doesn't have a \Program Files directory. It seems the %CE1% macro always resolves to that path and if the InstallDir specified in the inf file doesn't exist (with the exception of the last directory portion then the install fails. Manually creating \Program Files fixed the issue. Since a lot of the devices I'm working with have different paths for their Program Files directory, is there a generic way to get the installer to default to the actual Program Files dir? I guess my only other option is to not specify a path and force the user to choose one?
First, in this link you can find the shortcuts and their meaning (the %C..%), goto appendix B. The Windows CE5 MSDN link.
You can add a Setup Dll to your CAB installaer that will check the directory structure and will create a folder in case it does not exist. You may find this SO question useful.
A warning: If you are targeting regular Windows CE devices, beware where you place the files as it can be to a RAM based file system and then the files will disappear after reboot.