I am running into a very strange issue. I am sure its something small but I am pulling my hair out on this one...
I am working on integrating a third party lib into my application. I downloaded the lib and it came with sample code. I was able to build and run the sample code with no problem. I copy the lib + the sample code into my own solution folder without changing anything in both projects, added them into my own solution, built and run. I get ThreadAbortException at the end of my sample app. This used to work in separate folder?!!?!
The code opens a socket connection within a listening thread. The thread monitors and consumes the socket information. Then before the program exits, it does a runner.Abort() where runner is the thread. What I can't figure out, is why is it not throwing ThreadAbortException in its original unzipped folder. But when I copied exactly into my own solution it will throw?
I did not see any use of Thread.ResetAbort().
Need some help on this one. Thanks in advance.
What I have tried:
Changing .net framework version(no matter how I change, original directory will run fine but my own solution will choke on ThreadAbortException)
This is on Visual Studio 2013 community edition.
Thank you for reading.
edited below***
Config files are identical. The bin directory shows the generated pdb files have size differences but other files seem to be identical in size. The code that did not work have smaller pdb files.
I deleted the original directory's bin for both the lib project and the sample project, removed the reference from the sample project and re-add it from the solution. built, and it builds the same size(bigger than other solution). Ran it and it exited fine without ThreadAbortException. Then I did the same thing under my own solution and it builts with smaller size pdb and the ThreadAbortException showed up
I also verified that both instances of Visual studio are 2013 community.
I ended up creating a brand new solution, put the third party projects in there. Then add my old projects in the new solution one by one. It is still unclear to me why it happened. But I am going to move on for now.
Related
I was working on a WPF application in Visual Studio 2015 and all went well until unexpectedly the build dropped me the CS2012 error inform me that it cannot access/update the executable in the /Debug directory.
I tried the following and it didn't work:
Restart
Close VS and open the application again
Build->Clean
I couldn't find any solution in the web so I tried:
1. to move the whole project directory to another location.
2. creating a new WPF project and assembling it file by file with copy/pastes.
The weird thing was that in both cases the application worked in the new location. I continued the experimentation (in the original directory) and i tried to build a "Hello World" Console application in the same directory. The result was that the trivial console application didn't work and produced the same problem as the WPF application (CS2012 error).
Since I haven't noticed any activity of another program (i.e., antivirus) trying to quarantine (or changing the file/folder permissions of) this folder, I assume that this has been done by VS somehow but I don't know why. Perhaps it is a bug.
Is anyone has a logical explanation about this problem? And a way to fix it?
I found that my other running solution was referencing the same < executable path>.
Just make sure that no other process is using the referenced folder/file/dll
Try to close all processes, move the project to a different folder (on a different disk) b restart the computer and everything will work as it should. It worked for me without any problems. Hope this helps someone
I wanted to quickly test something in a .NET Core Console Application Solution and ran into this issue due to BitDefender blocking the resulting binaries.
I've named the app client which actually was the culprit. Renaming my solution fixed this.
Sometimes antivirus softwares can block copying an exe file from a folder to any path. You can manage by settings or the easiest way is to shut down live protection while you are coding and debugging.
:)
Deactivate your anti-virus for a while and try again.
This works for me.
I am dealing with a really huge work such that we have a solution and there are about 100-120 projects under it. Once I was trying to launch it but it took extra long I had to cancel it. Now a number of dll files under bin folder are lost, and most of those files were created by fellow projects under the solution.
Now I cannot rebuild/build.
Till now:
-have cleaned and tried to rebuild the solutions and project folders(each folder, is directly under solution contains like 5-6 projects) one by one. I also tried rebuilding projects one by one but it took too long and was useless.
-cleaned the solution, restarted visual studio(even the computer itself), but did not worked.
-cleared the Temporary ASP.NET Files under C:\Windows\microsoft\\ TEmp... and failed to relaunch again.
-Also tried to manually add missing references to projects but since there are over 100 projects it is not useful and will not work.
Any help will be appreciated greatly.
Thank you for your time.
try everything...(in order of a little to a lot of time wasted)
Do you have bad code? Fix that first.
Clean Solution & Restart Visual Studio
Remove / Add References
Check your build order w/ larger projects and verify
Manually rebuild sub-projects
Manually copy dlls between projects into associated bin folders
Go get some coffee, play some pinball and come back tomorrow...you may think of something else in the meanwhile.
I've been there before, it is a painful process. After you do what Vignesh told you, or while you do that, you can also use Dependency Walker to help figure out which dependencies are missing. This tool from the old days is still available for free and has helped a poor soul many times over. The main download page is dependencywalker dot com.
An additional tool to use is CheckAsm. Simplified, CheckAsm is a dependency walker for .NET.
It shows all .NET assembly references for any of your .NET assemblies. This tool is located at amberfish dot net. (They have an evaluation version which is free.)
I wish you well.
We decided to delete the current solution and get it back from TFS and it resolved our problem.
net project that runs but gives me a 404 when I click on links and 1/2 the images are showing up. Also when I try to debug the issue I get "source code is different from the original version" on the break points. I have tried:
Clean
Rebuild
Did not work.
I added a page handler to the web.config did not work.
I deleted the bin files and my project went crazy and found a 258 bugs including the global asax thinking that the Inherits is wrong. So I restored the files, something is up with the project I just don't know what.
Its visual studio 2010 running local on a windows 7 computer all my other sites work just fine so I don't think its a iis thing.
Thanks for any help!
Tim
Try cleaning your solution, if that doesn't work delete the bin and obj directories and rebuild. Sometimes an old dll is hanging around in there that may have classes with the same name.
I created a new project and added the old files in to the project and everything is working now.
Recently we have been having problems with TFS and our code base. We have a section of tests that use Webdriver, and a section that use Coded UI. Lately, we've been having problems merging our code after a new build has been pushed out. Some folders show up as a white outline of a folder, which we can right click and select "include in project". We also notice some files missing, and we can't "get latest" to grab them. We have to go some round about way to do it (shelve code, delete local files, get latest, merge code). Even when we do that we still have some issues.
But the main issue we are having is that our Coded UI maps are breaking. Instead of being the normal structure such as:
.uitest
----.cs
----.designer.cs
When we merge in the new code, the UI maps break out like:
.cs
----.designer.cs
.uitest
I opened the .csproj in notepad++ and noticed that both the .cs and .designer.cs files no longer have a dependancy of the .uitest file. Now the .cs file has no dependancy, and the .designer is dependant on the .cs file. We can fix it with relative ease, but it keeps breaking in every build and we have several maps we need to fix. What exactly could the problem be here? Also, referring to my frist problems of files not being included in the project, what could the issue be there?
I asked the same question on the MSDN forums, but the suggestions I have received I have already tried, like creating a new workspace since the other might be corrupt. Still didn't work.
Thanks in advance
Edit: Had a suggestion on the MSDN forums to run VS as administrator. That didn't work either. Not really sure what could be causing this issue. It doesn't seem to be causing problems for everybody because some new builds cause issues for some people but not others. Some more info would be I run on Windows 7 64bit and Visual Studio Ultimate 2010.
In the past I've had issues with TFS that sound similar, 2 of our developers seemed to periodically create problems when merging files into the data store, folders and files would show as not included while the project file would make it in (breaking everything after get latest). Eventually the problem went away but we never truly found the source. I believe it had something to do with our network - maybe a switch issue in combo with the way we mapped working folders to network drives pointing to a shared dev server. Also one of the workstations seemed to have a problem with windows explorer not seeing file updates on the dev server share... developer would have to hit \servername\C$\sharefolder then hit his mapped network drive again before updates would refresh. (And his check in's created the most problems) ... we ran VS2008, TFS2010
Just some ideas...
I have two applications developed in VS2010 (C#, .NET 4.0) - each is a separate solution with 2 projects, one for the app-specific elements, plus the project for a shared library which builds a DLL.
My problem is when this DLL is built, under one of the builds the DLL is 16384 bytes (0x4000) larger than it should be. This size difference is the same for both Debug and Release builds. WHile the proper version is within ClearCase, I get exactly the same result with a copy on the C: drive, so it doesn't seem to be a config-spec or view-related issue.
I've trawled through the VS settings, completely removed the bin/obj folders to force a complete rebuild, used WinMerge to diff all the files/folders, all with no success.
Using dumpbin, I can see in the clr header a 0x3F20 size difference for the Resources Directory. I suspect the remaining 0xE0 is attributable to section alignment within the DLL.
At this point I'm stumped. Any suggestions on what could be causing this or what steps to investigate further???
EDIT:
Maybe I didn't describe the VS solution very well - The solution has 2 projects. The shared library is simply added to the solution via Add->Existing Project. Both projects are then built when selecting Build->Rebuild Solution.
Re. Hans' comment, it's a problem from a configuration management/confidence standpoint. If no source code/project files have changed, the only thing I'd expect to change in the DLL is any build time/version details - not a 15K delta like I have.
The problem was in the .suo (Solution User Options) file, which must have been corrupted (and unfortunately placed and maintained under version control by previous users). Thankfully it appears nothing significant is lost by the removal of this file.
A little more info on .suo files can be found in the SO question Why are there sln, suo and csproj files?
A quote from Debugger Settings Visual Studio Add In– Easily Copy Breakpoints between Machines sums it up well:
The .SUO file is the bane of your existence. Nearly all the problems you encounter with Visual Studio are the result of a corrupt .SUO file. Sadly, it seems all it takes to corrupt the .SUO file is your heart beating. In other words, whenever you have Visual Studio crash, refuse to debug, or behave strangely it's the .SUO file's fault. Whenever anyone asks me about strange Visual Studio behavior, my instantaneous response is "Delete the .SUO!" When it comes to Visual Studio hygiene, deleting the .SUO file is right up there with cancer screenings.