We have a CI build and a nightly build which used to work perfectly but all of a sudden it started failing. I have been analyzing the log to see what the issue is but the log keeps complaining about random files already existing. The only common thing about these files is they are .resx files. I get this message:
CoreResGen:
2017-01-29T05:01:39.1421685Z Processing resource file "Resources\SomeRandFile.resx" into "obj\Release\Xxx.Model.Resources.SomeRandomResources.resources".
'##[error]C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\SSDT\Microsoft.Data.Tools.Schema.SqlTasks.targets(550,5): Error MSB4018: The "SqlBuildTask" task failed unexpectedly.
Everything used to work and then one day it just stopped. I have spent a few days looking for this error and here are what I have tried so far:
Delete the Windows\Temp folder
Delete the AppData\Local\Temp folder
Turn the Clean flag on in the Repository tab.
and nothing is working.
Really appreciate if anyone has come across this and how you resolved it.
Just a note: The exact same code works locally on my dev machine. But fails on the build server.
I built an older changeset which was successfully built a few weeks ago to see if that will fail as well. I wanted to make sure it is not related to a checkin. As I expected, the build with that changeset failed with the same error. Ok good so at least we know it is not related to a checkin.
Then I created another build and kept modifying it to build a different a random project from my solution. My solution has around 50 projects so I started picking projects at random and built them. After a few builds the project which failed with the exact same error was my database project. Another small step towards the solution. Ok good we are getting somewhere.
I then installed the latest version of SQL Server Data Tools and tried rebuilding the project and it failed with the same error. Then, I installed Update 3 of VS 2015. Retried, failed again with the same error.
I found the ...\UserAccountUsedByTfsBuild\AppData\Local\Temp and decided to delete everything from it once again. Gave the build another try, failed with a different error:
Error CS2001: Source file 'C:\Users\UserAccountUsedByTfsBuild\AppData\Local\Temp.NETFramework,Version=v4.0.SqlClrAttributes.cs' could not be found.
OK great! Different error. I just went into another user's temp folder and copied the following C# files:
.NETFramework,Version=v4.0.SqlClrAttributes
.NETFramework,Version=v4.5.2.AssemblyAttributes
.NETFramework,Version=v4.5.AssemblyAttributes
I ran the build again and YESSS IT PASSED!!
Then I ran the build for the whole solution and it passed too.
CONCLUSION / SUMMARY
Install the latest SQL Server Data Tools
Install the updates for VS 2015
Delete the temp file for the account used by TFS build (DO NOT delete the files starting with .NETFramework...)
Related
When I build my Specflow solution, I get the following error:
C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\MSBuild\Current\Bin\Microsoft.Common.CurrentVersion.targets(4651,5): error MSB3021: Unable to copy file "<myUser>\.nuget\packages\specrun.runner\3.1.48\tools\netcoreapp3.1\TechTalk.SpecRun.Framework.Executor.anycpu.netcoreapp3_1.runtimeconfig.json" to "bin\Debug\netcoreapp3.1\SpecFlowPlusRunner\netcoreapp3.1\\TechTalk.SpecRun.Framework.Executor.anycpu.netcoreapp3_1.runtimeconfig.json". Could not find a part of the path 'bin\Debug\netcoreapp3.1\SpecFlowPlusRunner\netcoreapp3.1\\TechTalk.SpecRun.Framework.Executor.anycpu.netcoreapp3_1.runtimeconfig.json'.
I can see that the path is wrong, there are two \\ instead of one but I have no idea where the path comes from. The solution worked until two hours ago and I haven't changed anything but code in it. Are there any VS or PC configurations/paths and where should I search for them?
Deleting \obj, \bin, \.vs, restarting VS, restarting PC, copying the files per hand, updating to another SpecFlow versions, and everything else I could think of didn't help. The file Microsoft.Common.CurrentVersion.targets hasn't been changed. I am able to build other Specflow solutions (with .NET Framework, I don't have others with .NET Core).
Any ideas?
Update
We tested on the PC of another colleague and the issue occurred there as well, so it is not a problem of my PC.
Also, I switched on the build logging and could see that all SpecRunner paths have the same issue with two \\
I had the exact same error. Created my project in an above folder, it worked.
Seems like the filepath was too long.
After 2-3 days the problem disappeared. Without any changes on my side. My colleagues could also build the solutions. Quite strange but main thing is that it works now.
I have several ASP.Net web form apps in a Visual Studio project. In one of the apps, I was working to add a test page for some additional features we wanted to test before adding to our main pages. Afterwards however, I was trying to publish to our server, but keep getting a message box saying: "The publish has failed due to one or more errors.".
Build succeeded Image
Publish Failed Image
I checked the errors, but none are given. The build was successful and other then a few un-used references, there are no other indicators on what the issue exactly is. We have a few other projects that normally allow for publishing without issues. So I don't believe the issue is from Visual Studio, but I am not completely sure. I'm using Visual Studio 2015 version 14.0.24720.00
Figured it out!
There is a Thumbs.db file that was auto-generated in the images folder. I decided to go through the output window line by line to see if I could identify where the publish was failing at. I noticed a line that said the /Images/Thumbs.db file could not be published and that access was denied.
Doing some more online investigating, I found some other questions along the same line as the premise for this one. Specifically the question here was most helpful. Tammy Spencer's (#user:973679) answer to try and delete the file was what made the publish succeed. So thank you Tammy.
In addition, the Thumbs.db file wouldn't let me delete it at first. But after doing some more searching, I found this YouTube video that made the file deletable.
I've been using Microsoft Visual C# 2008 Express Edition for the past two years. I made some very slight changes to a single project last night and now want to open the project and make a couple of changes. Out of the blue I'm getting the following message when I try to load the project:
Unable to read the project file 'myfile.csproj' Could not load file or assembly 'sorttbls.nlp' or one of its dependencies. Incorrect function. (Exception from HRESULT: 0x80070001)
The above message stops me from accessing any part of the project. (I am able to load the source code in Notepad so at least I don't have to worry about losing the code altogether). This error does not seem to be associated to any recent changes to my code as I run into this error when open up a simple console project or try to create a new project. What happened? (Did my computer get infected with a virus?) How do I get past this?
Thanks!
May be you can use following source
sorttbls.nlp Problem
According to which you can uninstall and install .Net 2 or 3.5 and perform Reboot
If you have ATI card above link might solve your problem
When I try to build my project, it returns the following error:
Error 1 Unexpected error creating debug information file 'D:\Documents\Lance\Documents\School\Capstone\GG\GG\obj\Debug\GG.PDB' -- '' GG
I've recently had the misfortune of having my PC restart on me, due to sudden power supply problems (maybe). This is while the project was building, before this problem started.
When the PC came back online I've noticed that the changes I've made to the program prior to the sudden power down was not saved. And, it won't build anymore.
This worked for me:
Shut down VS.NET
Browse to the project in Windows Explorer
Delete the /obj/ folder.
Delete the project outputs (.dll and .pdb) from /bin (not sure if this step is necessary)
Can't hurt but might help: delete the project outputs from any other project /bin folders in the solution that is having issues (wasn't necessary for me)
Restart VS.NET
Rebuild
http://weblogs.asp.net/ssmith/archive/2003/08/12/23755.aspx
As requested, my comment as an answer:
Try cleaning the solution (under the Build menu in VS).
Since the build was interrupted half-way through by your power failure, the file isn't locked -- the build system is probably just in an inconsistent state (which a Clean Solution should fix).
This happens once in a while in my environment and the problem probably has to do with the PDB file being locked (i.e., I'm guessing the last part of the error message is missing in your post). This is how it looks on my machine:
Unexpected error creating debug information file 'c:\dir\obj\file.PDB' -- 'c:\dir\obj\file.PDB: The process cannot access the file because it is being used by another process.'
In my case, cleaning the solution does not solve the problem and restarting is an overkill, so I usually just copy the full name of the pdb file (from the error) and execute this on the command line:
ren c:\dir\obj\file.PDB *.old
This worked for me: Close Visual studio and open visual studio using Run as Administrator and problem was solved.
Not need to restart or delete the file.
Just rename the file and that is enough. If you try to delete the file it will give an error. Better just rename it & it will work. :)
If you are having this problem with a web application, this can happen in the unusual situation that you have used DebugDiag and created a rule that listens on your project's app pool. Deleting the rule prevented this problem from recurring.
This might happen, for example, if you followed these instructions for diagnosing a stack overflow exception in IIS.
If you are working on VM with two user, make sure the other user has not attached all the process while debugging.
Cons of restarting VS:
Clipboard will be lost
Redo/undo will be lost
Files open will be lost
You will loose the tempo
Solution:
Give your Assembly a new name. No cons. Except you will have to rename your assembly back to its original name when you are ready for final deployment. And I think anyone can find how to make it work for the last time :)
Sometimes all the files from \bin folder are used by a running process, i.e. web site on IIS or windows service run automatically after build. In such cases turning off the service or stoping IIS app pool for specific site should also help (like in my case)
Sometimes I run into this problem, when compiling the same project for (very) different targets:
VS2008 and net35
VS2017 and net462
dotnet core 2.0
My guess is, that either bin and/Or obj directory are used by the compiler, but the outputs are not compatible (of course). Solution clean from VS indeed helps.
Often we specify different dll names for the output (e.g. mylib.dll, mylib35.dll) and the issue never happened on those projects.
I'm working on a moderately sized WebForms project. Due to the peculiarities of management here, I have to upload the site to a remote server in order to test (no localhost testing). I'm using the 'Publish' command in Visual Studio 2008. Sometimes, it even works. Most of the time, I inexplicably get a "publish failed" in the bottom left corner, with no further details.
The few googled articles/forum posts I read suggested making the target local folder for the publish operation readable/writable for everyone. Doesn't help.
Is there are way to get further details as to WHY a publish fails in VS2008, and if not, is there a better way of doing these deployments? I'm spending more time building/pushing to the web server than actually debugging.
It's worth checking the output window. I've just had a publish fail because I had deleted an image outside of VS so VS was complaining that the image couldn't be found, but this information was only displayed in the output window.
See this link for more information:
http://ericfickes.com/2009/08/find-out-why-visual-studios-publish-fails/
It happens to us when there is an error in markup (!). Bad thing is that VS will just swallow the error and just tell you Failed.
What I suggest is to run your publish from command line using MSBuild. It's not that straightforward but it works (once you get into it).
I've since discovered that the reason for these particular publish failures was due the "Delete Existing Files" option being checked. Using Visual Studio 2008 under a non-administrative account on Windows Vista could cause a permissions error while attempting to delete the existing files. The publish would fail silently after encountering a file that Visual Studio had insufficient access to delete. Once the files were deleted manually outside of Vidual Studio, the publish functioned normally.
I have not had this issue with Windows 7; I assume the UAC changes in Windows 7 fixed the problem.
I mostly work with Web Forms, and I encounter this problem daily.
It seems to me that publish fails when it fails to delete a file it is trying to replace. Even if I don't have any files open, it still fails sometimes. Not sure why.
Not only VS publish fails very often, it is painfully slow as well.
I just publish to empty local directory and use separate FTP client to upload files. It's more work, but works.
This is probably not the case for you, but I've seen this happen when I'm publishing a web site. If the app_offline.htm file is not excluded from your project (if you use this file), the publish will fail.
Same happened to me.. what I did was include images files that was not included in the project and delete images that were not used.
After struggling with a similar issue for about 30 mins with no clue as to what was causing it closed down VS and reopened my project. Started working fine. No idea why but it worked.
You should always stop the IIS instance running on the machine your are publishing to. Google the word "iisreset". Other hosting providers like DiscountAsp and Arvixe offer you tools to "Stop" and "Start" your app pool on their IIS remotely. This is very necessary because IIS may have locked some files as "in use", so your publish fails when it tries to write over them. When your publish is complete, then just restart IIS (or press "Start" from a web tool if you're using a 3rd party hosting provider).
When all else fails, check your "Output" window (the tab to the right of your "Error List" at the bottom of Visual Studio). Scroll through all of it after a failed publish and look for anything that says "Unable to add". If you keep seeing the same "Unable to add" errors on the same publish, then ftp into the folder, delete the the problematic files manually, and try publishing again.
I got this when my ProjectName.Publish.xml file was read-only. Once I checked the file out of source control, I no longer got the error and could publish.
Just to add to this thread, I found that, for some bizarre reason, only the Mercurial files were being published to the server, everything else just wasn't being copied across.
Another strange thing was that only the Debug configuration was available; Release was nowhere to be seen.
After reading other threads around S.O., I found that there were many for VS 2010 and 2012, but not much to cover the same problem with 2008.
The fix, I found, was to delete the [solution].suo file and then attempt a publish. That seemed to do the job, though it took a long time to complete.
What I found and work in my case. It is to use a different version of VS.
I recently had the problem, the solution works perfectly in VS2015 build, compile and tested.
However, when I try to publish was failing silently.
So, I closed the solution and open it with VS2017 that use the same file structure for the projects/solutions. Then rebuild it and publish without any problems.
I believe it could be VS related and it is complicated to debug.
This is a workaround if you work with multiple Vs instances in your local machine.