I am trying to build a C++ program in VS2010 and encountered an error that I've never seen before.
LINK: fatal error LNK1104: cannot open file C:...\Debug\labfour.ilk
I searched for solutions but wasn't able to find any other instances of visual studio linker being unable to open the .ilk file. Does anyone know why something like this would happen? I'm wondering if there's a solution that's similar to that of the error cannot find or open the PDB file, where you have to adjust some of the settings in the solution explorer properties.
Any insight would be greatly appreciated, thank you.
In my experience this is one of two things:
The .ilk file is broken. Just clean and rebuild; if that doesn't purge the .ilk file then whack it yourself. This file is prone to getting broken, in case of cancelled builds usually I think.
You're building two projects configured to write the same .ilk file, or using incremental linking (Linker>General>Enable Incremental Linking) + /MP (C/C++>General/multi-processor compilation). This can fail intermittently and sometimes when it fails it can break the .ilk file. I'm less confident about this scenario though.
Related
I've had a problem with my Windows 7 after an update, neither Safe Mode nor Recovery Mode could resolve the problem. I was forced to reinstall Windows completely. To develop on my projects I need Visual Studio 2010.
I always had ReSharper installed and got used to its features, so I installed it aswell.
Everything setup I tried building my solution but encountered a problem ...
(The underlined file can be found here: https://up.zone/aj)
After hours of trying to resolve the problems, I figgured out that ReSharper was the problem. I can build the solution perfectly fine without ReSharper installed. Having it installed, even if all features are turned off and the services are suspended, causes these errors in the picture above to show on build.
I managed to resolve two out of three errors by following the instructions of this Reddit user on his post: https://up.zone/ag
Now I am left with one more exception I cannot figgure out how to resolve. I couldn't really find anything helpful googling, which means you guys are my last hope. I really do not want to go back to developing without ReSharper.
This is the one:
Any idea?
Thank you!
Update 1
I figgured out that the problem must be in the NuGet.targets file, located in the .nuget folder in our solution.
I managed to find a workaround following the suggestion of this post, I am now able to build the solution without any errors.
To summarize, remove this line out of your *.csproj file
<Import Project="$(SolutionDir)\.nuget\nuget.targets" />
Although this works, I don't think this can be the solution. This line is there for a reason I assume. Anybody with a deep understanding of NuGet who might know how to properly resolve this problem?
Update 2
I found out that as soon as you reload your solution/project, the line gets added once again. Also, if you have certain dependencies nuget should download for you - it won't, because the line which makes that call and handles this got removed.
I'm now at a point where I know where the problem is but not why it is caused.
Does ReSharper change anything in the way NuGet behaves? As far as I can tell, nothing gets added or removed to or from the NuGet.targets file due to ReSharper.
There were one more report on this topic, at https://youtrack.jetbrains.com/issue/RSRP-462271 .
The best guess so far is that this is caused by two things happening at once: (a) using MSBuild tasks in C# source code form inside MSBuild XML files rather than DLLs and (b) having some of the MSBuild opensource DLLs shipped with the latest version of ReSharper for its own project file handling needs.
The source code gets compiled into a task DLL during an MSBuild run (not a much common thing to have; Roslyn would do this rather than ship a DLL? seriously?). When building from within Visual Studio (rather than with msbuild.exe), the in-process MSBuild instance is used, and it would run in the same appdomain as ReSharper, so it uses the common assembly reference resoluiton. If it's not too accurate, then it might accidentally pick the wrong DLL version by the short name, which would break the task compilation (that's a separate error, maybe cached away) and then result in the task-not-found error later at runtime (SetEnvironmentVariable task not found in here case).
I've tested on sample solutions with source code based tasks and could not get it broken. So trivial cases are OK. Never heard back from the original issue reporter, so there was no further progress.
Now I've got a hint that this is Visual Studio 10 (any other VS versions installed on that machine?) and maaaaybe it's Roslyn tasks. We might know for sure if you run MSBuild with more detailed logs (by setting the logging options at Tools | Options | Projects and Solutions | Build and Run | MSBuild project build output verbosity to at least Detailed) and building just the faulty project.
I'll also try this out with VS10 and update this reply with new data.
I am trying to get started working with CUDA.
I fresh installed the trial version of VS2010 professional and downloaded the visual studio add on on NVIDIA's website (here )
I have a correct driver version installed, and the Nsight add on automatically installs the CUDA Toolkit.
Problem is, whatever CUDA project I try to compile, I always get this error :
1> Compiling CUDA source file kernel.cu...
1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\BuildCustomizations\CUDA 4.2.targets(361,9): error MSB3686: Unable to create Xaml task. Compilation failed.
1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\BuildCustomizations\CUDA 4.2.targets(361,9): error MSB3686: Source file 'C:\Windows\TEMP\uq13nrom.0.cs' could not be found
1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\BuildCustomizations\CUDA 4.2.targets(361,9): error MSB3686: No inputs specified
1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\BuildCustomizations\CUDA 4.2.targets(361,9): error MSB3686:
1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\BuildCustomizations\CUDA 4.2.targets(361,9): error MSB4036: The "CudaCompile" task was not found
Even when using the solutions provided in CUDA samples
I never used Visual Studio before, and I could not find ANY resource on the web related to this error.
I spent the whole day trying to fix it. I also tried to uninstall/reinstall everything; no success.
What drives me crazy is that right after the install my projects actually did build for an hour or two. And for a reason I can't explain, everything started failing.
I'd be really, really glad for any information you could give me. I don't see any other way to solve this.
So, I woke up this morning and directly got in front of the computer, a coffee in the hand, already expecting to spend the whole day just trying to get my tools working
. . . till I realized everything was working fine.
The very same code that leads to the error at midnight compiles just perfectly this morning .
The only difference ? Updates in Visual Studio.
Here is a screenshot of all the updates that have been applied during my sleep :
I bet one of those guys solved my problem, probably the .NET framework 4 related.
Hope this can help someone ;)
It has nothing to do with configuration. There is something messed up [by me/you] in the project setting file. I am facing this problem while updating an old project from CUDA 4.4 to CUDA 5.5. I tried modifying the old project file according to one of the new project files... changing build target and other related things................
New project is compile and executing, whereas, the old updating project lead me to this page. I'll update the thread with a solution later. Definitely, it is not .NET framework or any updates in my case
EDIT: I copied the .prop and other files from CUDA installation directory to Visual Studio directory and it started working again. Perhaps, I modified these files incorrectly.
Visual Studio sometimes decides to rebuild my entire huge project because of one small change. I turned build logging up to Diagnostic to see what was the problem, and here's what I'm seeing:
< Bunch of spam >
Outputs for C:\<snip>\PRECOMPILEDHEADERS.CPP:
C:\<snip>\PRECOMPILEDHEADERS.OBJ
All outputs are up-to-date.
Forcing rebuild of all source files due to a change in the command line
... and then it rebuilds my precompiled headers, then everything else.
This happens when I change a single .cpp or .h file inside the project. I'm not changing anything in the project settings. It also doesn't happen all the time for the same change; it's random.
Any ideas on what's going on here? Where can I get more information? I tried enabling debugging via the description in http://blogs.msdn.com/b/vsproject/archive/2009/07/21/enable-c-project-system-logging.aspx but it didn't give any more information. I can't figure out where this "Forcing rebuild of all source files due to a change in the command line" is coming from. It's not in any of the factory MSBuild files.
Some other info: it's a C++/CLI dll project that links a lot of other projects, including C#, native c++, and other C++/CLI dll's. I tried removing all the C# projects from the dependencies since those tend to cause problems, but that didn't change it. I've googled that specific string, but my situation doesn't match that of any of the other people reporting it. (One was using Intel C++, another was MSBuild from the command line and changing the case. I'm hitting build solution from within Visual Studio itself).
Edit to explain common fixes I've tried:
I've tried building only the project. Does the same thing.
I'm not including any .h files that don't exist.
I've deleted the bin/object folders and rebuilt from scratch. This usually makes it go away for a couple builds, but then it comes right back.
Edit #2:
Found something suspicious earlier in the log:
3>Using "ResolveNonMSBuildProjectOutput" task from assembly "Microsoft.Build.Tasks.v4.0, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a".
3>Task "ResolveNonMSBuildProjectOutput"
3> Resolving project reference "..\..\..\..\CommonCore\VS2010\Project1\Project1.vcxproj".
3> Project reference "..\..\..\..\CommonCore\VS2010\Project1\Project1.vcxproj" has not been resolved.
This is repeated for several of my projects... I'm gonna chase that down and see if maybe it's a problem with the project reference hint paths.
Ok, it's an old thread, but I encountered the same problem recently.
My solution was to disable the precompiled headers - now a simple change in one sourcefile won't lead into a "rebuild" any more.
I have had the same problem with Visual Studio 2012 recently. I'm on Windows 7 with Visual Studio 2012 Professional (2012.2) building C++ projects. It's worth noting that I recently migrated the solution from Visual Studio 2008 to Visual Studio 2012.
One of the C++ projects (an executable with a DLL project as a reference) was rebuilding every time one of its compilation units was changed, e.g. simply saving main.cpp would cause all compilation units (including the pre-compiled header) to rebuild. I spotted the the following message in the build logs:
Forcing rebuild of all source files due to a change in the command line since the last build.
I turned build log file verbosity to Diagnostic (Tools > Options > Projects and Solutions > Build and Run) and compared the log files from a clean build and a build after one compilation unit has been changed (which forced a full rebuild). I noticed that:
"Path" had changed from one build to the next (";C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\Extensions\Microsoft\VsGraphics" seems to have been tacked on the end)
there was a difference in TaskTracker.exe command lines to do with CancelEvents
there was a warning about OutputPath not being set
I pulled my hair out.
I eventually resorted to recreating the offending project from scratch rather than relying on the project that was automatically generated during the migration process from 2008 to 2012. It seems to be behaving as expected now.
I did three things, and the problem seems to have gone away. I'm trying to narrow it down a little but I figured I'd go ahead and post them:
Deleted and re-added all the references and project references
Fixed one of my projects that wasn't setting the .NET framework target to 3.5 to match the rest of my solution (I was getting away with it because the project didn't use .NET anyway)
Set "Copy Local Satellite Assemblies" to false for all references including System ones.
Beware that some or all of this stuff might be voodoo...
We just converted a VS 2008 project to VS 2010. The conversion showed no errors. Now, when building the solution. We get the following errors:
Unable to copy file C:\TI\Project\SharedAssemblies\Myfile.dll to bin\Myfile.dll Access to the path bin\Myfile.dll is denied
ANOTHER PROBLEM:
I have another problem too! One of my project is referencing a project DLL and that DLL does not exist. I tried to build the solution but that project is never building because it stops whenever there is error on any other project.
UPDATE 2:
So, instead of using the ported VS 2008 to VS 2010 solution I just opened the VS 2008 solution in VS 2010 and some of the errors have gone away. Now, I am left with couple of errors in which one of them is the following:
Error 1 Could not load referenced assembly "C:\MyProject\bin\JobManager.dll". Caught a FileNotFoundException saying "Could not load file or assembly 'C:\MyProject\bin\JobManager.dll' or one of its dependencies. The system cannot find the file specified.". C:\MyProject\ResGen
What kind of resources the resgen is trying to build and where is it located?
One common cause that I've encountered is that a unit test has the assembly loaded (like in NUnit) and that is blocking the copy. Closing NUnit, for example, clears the problem. Check for something similar that's holding on to the assembly.
I just removed the file from bin folder and everything start working
might be it help you!
I had been happily coding along on a decent sized solution (just over 13k LOC, 5 projects) which utilizes Linq to Sql for it's data access. All of sudden I performed a normal build and I received a sweet, sweet ambiguous message:
Error 1 Build failed due to validation errors in C:\xxx\xxx.dbml. Open the file and resolve the issues in the Error List, then try rebuilding the project. C:\xxx\xxx.dbml
I had not touched my data access layer for weeks and no adjustments had been made to the DBML file. I tried plenty of foolhardy tricks like re-creating the layout file, making copies and re-adding the existing files back to the project after restarting Visual Studio (in case of some file-level corruption); all to no avail.
I forgot to wear my Visual Studio Skills +5 talismans, so I began searching around and the only answer that I found which made sense was to reset my packages because Visual Studio was not loading an assembly correctly. After running "devenv.exe /resetskippkgs" I was, in fact, able to add the dbml file back to the DAL project and rebuild the solution.
I’m glad it’s fixed, but I would rather also gain a deeper understand from this experience. Does anyone know how or why this happens in Visual Studio 2008?
New Edit: 10/30/2008
THIS WAS NOT SOMETHING THAT JUST HAPPENED TO ME.
Rich Strahl recently wrote on his "web log" about the same experience. He links to another blog with the same issue and used the same action.
I have encountered this issue a few times since this original post as well, making me think that this is not some random issue. If anyone finds the definitive answer please post.
After installing Phalanger for Visual Studio 2008, I attempted to create a new PHP WinForms Application. The project creation failed with a similar error message, stating that a DLL required could not be loaded (Failed to load file or assembly...). Running the devenv.exe /resetskippkgs command in Visual Studio 2008 Command Promtp resolved the issue immediately.
Thanks for the info.
I also get this error when trying to compile the data access layer in the second solution (installer). What I do is that I run Custom Tool on the dbml-file, and this does it.
There is really no errors in the dbml file that needs to be corrected.
My theory in this is that Visual Studio caches the compiled version of the dbml file, and that the cache is invalid for other solutions. I guess running /resetskippkgs does the same thing as recompiling the dbml file.
Anyway, there are no fix for this yet?
TBH, I have had a couple of instances like this where files "seemed to go crazy".. However, upon investigation it has appeared that the files have changed in some way, shape or form.. (e.g. sometimes changes can be made to the file by inadvertantly changing a property somewhere that seems unrelated).
I think there are too many possible issues that could really cause this, and based on the fact that the problem has been resovled, it seems like an answer will not be found..
I had the same issue in VS 2010 (build failed due to validation errors in dbml file). I resolved this by viewing the designer view of the dbml file and dragging a table slightly to a different location so that it refreshed the dbml layout etc files. This seemed to do the trick, but was a bit of a weird issue.