Related
i got a problem with my site with my app_code files and a lot of question ive read people say you need to change the proprties of the .cs files to Build Action.
by right clicking the .cs files and press proprties.
but...
when i right clicking the files i cant see any option called proprties so i press F4 and it open a proprties window and i just click on the .cs file and still cant see any option i can change somthing to Build Action.
any idea why i cant see this options?
EDIT:
my problem is that when i get in the file proprties i have only 2 options...
thay are called:
1.Full Name
2.Full Path
EDIT2:
here what i see in visual studio 2010 when i try access the protrtie menu/window
http://img338.imageshack.us/img338/2359/blac.png
As Microsoft points out in the article "Web Application Projects versus Web Site Projects":
Web application projects use Visual Studio project files (.csproj or
.vbproj) to keep track of information about the project. Among other
tasks, this makes it possible to specify which files are included in
or excluded from the project, and therefore which files are compiled
during a build.
An answer to a similiar question at CodeProject's forums reveals a hint. Abstract:
[...] Looks like you are working on a web application that is actually a
Website as per Visual Studio. You would need to create a new Web Application
and probably copy over the source files there. [...]
http://www.codeproject.com/Questions/173637/Setting-Build-Action-for-Files-in-App_Data
Have you tried this:
You say you haven't got the option being suggested by other posters.
If this is the case, than it is quite possible that your Visual Studio settings are corrupt; this can give rise to all sorts of odd behaviour.
I would suggest you reset your settings, but please be aware you will lose any custom IDE settings that you've previously applied.
Try this:
In Visual Studio, go to Tools->Import and Export Settings
Choose "Reset All Settings" and click Next
Choose to save your current settings if you wish, or select "no" and then click next.
Choose the collection of settings( he IDE preset) you want, probably "Visual C# Development Settings"
Visual Studio will now revert all settings. Hopefully this will make the Build Action reappear.
[EDIT]
It might be worth trying safe mode too.
To do this, start up a "Visual Studio Command Prompt" from your start menu/programs list in Windows, and start Visual Studio with
devenv.exe /SafeMode
Does this make the options appear?
You can copy the file from Windows Explorer and paste it in the Solution Explorer. It will replace (or do nothing but incorporating it in the proj file) the file and recognize it as C#.
Normally you should see a Property named "Build Action" in the first line of the Property Window. This property should be set to "Compile".
Please select file and right click on it so that you will get following screen
Than click on the Properties you will get following screen
You can find build option in as a first option.
Any changes I make to my code aren't doing anything. I've even tried putting lines in that I know will crash my program, and nothing. It just keep running the old version. It's even loading old versions of files I've edited and saved.
There a 3 projects in my solution. 2 are pure C#. 1 is a WinForms application.
It sometimes happens that some files "are being used by another process".
Close your solution and delete all "bin" and "obj" subfolders of all your projects that are included in the solution.
Then open your solution again, execute "Clean solution" and build it again.
Check this setting in Tools/Options, then under Projects and Solutions>Build and Run.
On Run, when build or deployment errors occur:
My personal preference is for this value to be 'Do not launch'. It will prevent Visual Studio from launching the "last successful build".
Try Ctrl+Shift+B. This will build your solution (not just a particular project). Other environments might build when you save but this needs to be explicit in Visual Studio.
Had issue with saving code changes on VS2017 (mac) Version 7.3 Preview (7.3 build 740)
Only way to get file changes to save was to do File > Save All
Doing File>Save would act like the file saved. But, when I opened the file again and no changes were saved.
Ok, you need to add more detail, but you may want to have a look at this answer:
How to enable/disable compile errors warning in Visual Studio
delete Published DLL From Bin
file names -
projectName.ddl
projectName.pdb
delete these two files and run project
I had the same problem (Visual studio 2015 is not noticing my modifications in C# XAML files).
Problem solved by deleting 2 'debug' subfolders. One in the bin folder and one in the obj folder.
I met the same problem. the code changes is not saved.(you can see from the edit it is in Yellow color. e.g. indicating changes). SAVE and BUILD will not let it save the changes. i have to wait sometime, then it could possibly save success..
Deleting the whole project and the corresponding folder from local and check out the solution again. This worked for me=> VS2017
I solved the problem like this:
1. I closed the program
2. I opened the folder that contains the file (.csproj) and opened it with Visual Studio.
Next, I chose the folder to run the command as in the image
Had the same problem. Turns out I had moved a project folder. Even when opening the solution from the moved folder and editing and saving this source code, VS 2019 was building and running a different instance of the program with the same name. Go to File-> Save yourproject.cs as..and manually walk back through the directory structure to find the instance VS is actually running. Hope this helps.
also check another option in Tools>Build and Run>Only build startup project & dependencies if you have more than 1 nested dependency, especially when using Prism or any other reflection-based frameworks that prevent "dependency detection". Also, make sure you're in the editor when using shortcuts like Ctrl+S (Save) or Ctrl+Shift+S (Save all)
Go to this location:
C:\Users\<your_system>\AppData\Local\Microsoft\VisualStudio\<studio_version>
Then remove all files and start Visual Studio.
this was the error , no changes made after build.
Is it possible to use environmental variables in the build output path in VS 2008 (et al)/ I'm trying to find a solution where several developers on my team using both Windows XP & 7 and all with different Windows logons, can all modify projects and common referenced dll's (source held on Source Safe) and not screw up the relative paths? I've tried such things as %userprofile% and $(userprofile).
I've looked into post build events but these do not really seem to provide an anawer to my problem. Sadly I'm not in the position to use 3rd party add-ons either as these will be non-commercial and it's nearly impossible to get authorization for any licences for them.
(Similar unanswered question at Output path for build in visual studio 2010)
You need to open the csproj file in a text editor and manually enter your environment variables in the OutputPath section. Visual Studio escapes the '$', '(' and ')' when you try to do this from the IDE.
I've used the subst command to accomplish this sort of thing in the past. Essentially all project references define paths in relation to a known drive letter like R:\MyProject\outputs.
Then every developer can map the R: drive (or whatever) to the folder structure particular to their environment. As long as the folder structure beneath the mapped drive is the same, the location of that mapped folder can vary between machines, builds, and users.
This works well as developers can then set up their environment with a simple batch file and easily switch between branches, projects etc and relative pathing within the projects is not broken.
PaulTee,
Is it a longshot to ask you try directory replication? Like Dropbox/Synctoy and other tools that invokes a file-copy from choosen location to the expected shared location?
In your situation, I would love to use the built-in environment variables. Probably there are a way to make it work, but until then i would go for such a solution. I would also have in mind that different users compiling to same directory, would make conflicts with both file versions and file locks (used by other user).
If you don't mind the extra copies, you could add post-build event that copies the project outputs to a commonly-agreed location for shared dlls, and everyone uses a non-relative reference to that location. It would still, though, require standardization of that target location, so maybe it is not what you are looking for. (example below would allow for drive letter independence at least)
copy $(TargetPath) \dependencies
While I don't quite understand what you're asking for, it sounds like symlinked directories will help -- you can configure the solution to output to some folder that will be symlinked to arbitrary locations on each individual box.
http://en.wikipedia.org/wiki/NTFS_symbolic_link
ghost edit - mklink is apparently new in 7, but older versions still support it (Russinovich to the rescue once again):
http://technet.microsoft.com/en-us/sysinternals/bb896768
This is driving me crazy.
I have a rather large project that I am trying to modify. I noticed earlier that when I typed DbCommand, visual studio did not do any syntax highlighting on it, and I am using using System.Data.Common.
Even though nothing was highlighted, the project seemed to be running fine in my browser. So I decided to run the debugger to see if things were really working as they should be.
Every time the class that didn't do the highlighting is called I get the "the source file is different from when the module was built" message.
I cleaned the solution and rebuilt it several times, deleted tmp files, followed all the directions here Getting "The source file is different from when the module was built.", restarted the web server and still it tells me the source files are different when they clearly are not.
I cannot test any of the code I have written today because of this.
How can the source be different than the binary when I just complied
it?
Is there any way to knock some sense into visual studio, or am
I just missing something?
I got this issue running a console app where the source that was different was the source that had the entry-point (static void Main). Deleting the bin and obj directories and doing a full rebuild seemed to correct this, but every time I made a code change, it would go out-of-date again.
The reason I found for this was:
I had checked "Only build startup projects and dependencies on Run" (Tools -> Options -> Projects and Solutions -> Build and Run)
In Configuration Manager, my start-up project didn't have "Build" checked
(For #2 -> accessible via the toolbar under the 'Debug/Release' drop down list.)
I was just having this same problem, my projects were all in the same solution so they were using Project to Project references, so as one changed the others should have been updated. However it was not the case, I tried to build, rebuild, close VS2010, pulled a new copy from our source control. None of this worked, what I finally ended up trying was right clicking on the project and rebuilding each project individually. That updated the .dlls and .pdb files so I could debug through.
The issue here is that your dll and or your pdb files are not in sync.
Follow these steps
Just delete the bin directory from the project where the DLL is generated.
Re-build the project.
Remove reference from the project that make reference to the DLL.
Include again the reference.
Enjoy.
In addition to these answers I had the same issue while replacing new DLLs with old ones because of the wrong path. If you are still getting this error you may not refer the wrong path for the DLLs. Go to IIS manager and click the website which uses your DLLs. On the right window click Advanced Settings and go to path of the Physical Path folder on File Explorer and be sure that you are using this folder to replace your DLLs.
Some things for you to check:
Have you double checked your project references?
Do you have a Visual Studio started web server still running? Check the system tray and look for a page with a cog icon (you may have more than one):
(source: msdn.com)
Right click and close/exit it. You may have more than one. Can you debug your changes now?
Are you running the debug version but have only built the release version (or vice versa)?
Did the compile actually succeed? I know I've clicked through the "there were errors, do you want to continue anyway?" message a couple of times without realising.
With web services, the problem can be caused by using the Visual Studio "View in Browser" command. This places the service's DLL and PDB files in the bin and obj folders. When stepping into the web service from a client, somehow Visual Studio uses the PDB in the bin (or obj) folder, but it uses the DLL in the project's output build folder. There are a couple workarounds:
Try deleting the DLL and PDB files in the web service bin and obj files.
Try clicking "View in Browser" in Visual Studio.
If you previously got the source file mismatch error, Visual Studio might have added the filename to a black list. Check your solution properties. Choose "Common Properties -> Debug Source Files" on the left side of the dialog box. If your web service source files appear in the field "Do not look for these source files", delete them.
Unload the project that has the file that is causing the error.
Reload the project.
Fixed
I just had this issue.
I tried all the above, but only this worked:
delete the .pdb file for the solution.
delete the offending .obj files (for the file being reported out of sync)
build the solution.
This fixed the issue for all builds moving forward for me.
In Visual Studio 2017 deleting the hidden .vs folder in the resolved this issue for me.
This is how I fixed the problem in Visual Studio 2010:
1) Change the 'Solutions Configurations' option from "Debug" to "Release"
2) Start debugging
3) Stop debugging and switch the 'Solutions Configurations' option back to "Debug"
This worked for me. Step 3 is optional - it was working fine when I changed it to "Release" but I wanted to change it back.
My solution:
I had included an existing project from a different solution in a new solution file.
I did not notice that when the existing project was rebuilt, it was putting the final output into the NEW solution's output directory. I had a linker path defined to look into the OLD solution's output directory.
Switching my project to search in the new solution's output directory fixed this issue for me.
I had this problem, and it turns out I was running my console application as a windows application. Switching the output type back to console fixed the issue.
I had the same problem. To fix it I used the "Release Mode" to debug in VS2013. Which is sufficient for me, because I'm working in a node js\c++ addon.
My problem was that I had two projects in my solution. The second one was a test project used to call the first one. I had picked the path to the references from the bin folder's release folder.
So whenever I made a change to the first project's code and rebuilt it, it would update the dlls in the debug folder but the calling project was pointing to the release folder, giving me the error, "the source file is different from when the module was built."
Once I deleted the reference to the main project's dll in the release folder and set it to the dll in the debug folder, the issue went away.
In my case, the #Eliott's answer doesn't work.
To solve this problem I had Exclude/Include From Project my deficient file, andalso Clean and Rebuild the solution.
After these actions, my file with my last modifications and the debugger are restored.
I hope this help.
solution:-
the problem is:-
if your some projects in a solution , refer to some other projects,
then sometimes the dll of some projects, will not update automatically, whenever you build the solution,
some projects will have previous build dlls, not latest dlls
you have to go manually and copy the dll of latest build project into referenced project
I was using Visual Studio 2013 and I had an existing project under source control.
I had downloaded a fresh copy from source control to a new directory.
After making changes to the fresh copy, when building I received the error in question.
My solution:
1) Open Documents\IISExpress\config\applicationhost.config
2) Update virtualDirectory node with directory to the fresh copy and save.
My problem was that I had a webservice in the project and I changed the build path.
Restoring the default build path solved my issue.
I had this same problem and I followed the majority of the guidance in the other answers posted here, nothing seemed to work for me.
I eventually opened IIS and recycled the application pool for my web application. I have IIS version 8.5.9600, I right-clicked my web application, then: Deploy > Recycle > Recycle application pool > OK.
That seems to have fixed it, breakpoints now being hit as expected. I think that doing this along with deleting the bin and obj folders helped my situation.
Good luck!
I know this is an old question but I just had the same problem and wanted to post here in case it helps someone else. I got a new computer and the IT dept merged my old computer with the new one. When I set up TFS, I mapped a different local path than what I was previously using, to an additional internal drive. The old path still existed from the merged data on my hard drive so I could still build and run. My IIS paths were also pointing to the old directory. Once I updated IIS to the correct path, I was able to debug just fine. I also deleted the old directory for good measure.
I also experienced that. I just open the obj folder on the project and then open the debug folder delete the .pdb file and that's all.
This error also happens if you try to make changes to a source file that is not part of the project.
I was debugging a method from a .dll of another one of my projects, where Visual Studio had quite helpfully loaded the source because the .dll had been built on the same machine and it knew the path to the source. Obviously, changing such a file isn't going to do anything unless you rebuild the referenced project.
Delete all breakpoints.
Rebuild.
Done
At Visual Studio 2015, using C++, what fixed for me the the source file is different from when the module was built problem was
restart Visual Studio.
Check if the location you pointed to using mex() in Matlab is correct (contains lib and obj files which are modified to the last date you compiled the library in Visual studio).
If this is not the case:
Make sure you are compiling Visual studio in a mode that saves .lib files :
properties -> Config properties -> General -> Config type -> static library
properties -> Config properties -> General -> Target extension=.lib (instead of exe)
Make sure the output and intermediate directories match the Matlab directory in
properties -> Config properties -> General -> Output directory
properties -> Config properties -> General -> Intermediate directory
I get this issue when debugging sometimes w/ Visual Studio but when the application is served by IIS. (we have to develop in this form for some complicated reasons that have to do with how the original developer setup this project.)
When I change the file and rebuild, that fixes it a lot of the time. I know that sounds silly, but I was just trying to debug some code to see why it's doing something weird when I haven't changed it in a while, and I tried a dozen things from this page, but it was fixed just by changing the file..
In my case, the problem was that the debugger exe path was pointing to a net5.0 bin folder. I am using net6.0, so I should've updated the exe path back when I updated the target framework. Works fine now.
Debug-> start without debugging.
This option worked for me. Hope this helps!
I have a project in C# and I get this error every time I try to compile the project:
(Unable to copy file "obj\Debug\Project1.exe" to "bin\Debug\Project1.exe". The process cannot access the file 'bin\Debug\Project1.exe' because it is being used by another process.)
So I have to close the process from the task manager. My project is only one form and there is no multi-threading.
What is the solution (without restarting VS or killing the process)?
This should work.
Go to your project properties.
Inside Build Events, under Pre-build event command line, add these two lines of code:
if exist "$(TargetPath).locked" del "$(TargetPath).locked"
if exist "$(TargetPath)" if not exist "$(TargetPath).locked" move "$(TargetPath)" "$(TargetPath).locked"
#Udpate: Since the time I was first posting this 'answer', I tend to another explanation to the problem. The issue since than happened more and more often outside of Visual Studio also - while trying to copy an .exe file from one folder to another. While in the first place Windows did not allow to copy(!) an .exe file (it was first asking me for administrative rights but refused to copy it afterwards anyway) it still showed up in the explorer. But after a while - without any further action taken, it disappeared magically. Just like the problem in the question always seems to solve itself after a while. So i assume, the problem is more related to a delayed deletion of the project output file and less a buggy VS. I apologize for any unjustified suspicion. :|
This gives the search for a solution a complete different direction, I guess. Did find that link and will update on any progress:
https://superuser.com/questions/234569/windows-7-delayed-file-delete
========================================================================
This is a known bug in VS. I discovered it very often - mostly in VS2010 (with/without SP1). Several "solutions" are recommended. Some of them, which kind of helped for me:
Delete the .suo file in your project dir. Eventually need to create your whole solution from scratch.
Close any Windows Form Designers may remain open.
Use a prebuild script, which deletes the target from the output dir.
Disable the VS hosting process.
None of these really fixes the bug. But it may brings the VS back to a usable state - until a true solution is provided by MS (if ever will).
http://social.msdn.microsoft.com/Forums/en/vsdebug/thread/cea5e4b2-5b33-453c-bffb-8da9f1a1fa4a
http://social.msdn.microsoft.com/Forums/en/vbide/thread/cd12f3c7-de96-4353-adce-23975e30933f
I can confirm this bug exists in VS 2012 Update 2 also.
My work-around is to:
Clean Solution (and do nothing else)
Close all open documents/files in the solution
Exit VS 2012
Run VS 2012
Build Solution
I don't know if this is relevant or not, but my project uses "Linked" in class files from other projects - it's a Silverlight 5 project and the only way to share a class that is .NET and SL compatible is to link the files.
Something to consider ... look for linked files across projects in a single solution.
This is happening because [yourProjectName].exe process is not closing after finishing debugging.
There are two solutions to this problem.
Every time you make change to application, Go to Task Manager -> Processes -> [yourProjectName].exe, end this process. You have to end this process every time you make changes to system.
Add a exit button in your application to exit window and add these line to click event
System.Diagnostics.Process.GetCurrentProcess().Kill();
Application.Exit();
If you look in the obj directory, and you don't see your .exe, it's possible that Avast! or other antivirus is deleting it. I would actually see the .exe show up and then disappear. As soon as I turned off Avast!, problem solved.
VS2010 throwing "Could not copy the file "obj\x86\Debug\[file].exe" because it was not found."
The real problem isn't the error you're getting; it's that the application isn't cleaning up after itself.
It's either holding on to references, not freeing resources, or something else that's causing the process to not end when it's being told to close. Fix up that issue and this problem will resolve itself. We can't really help you with that unless you post your code (and at this point, if you need help with that, you should start a new question).
I had to go into windows explorer and delete the bin/debug folder as well as the obj/debug folders. Then I cleaned & rebuilt the project.
Close your project
Delete bin folder
i find it work, :)
Rename the assembly to a different name to solve this issue.
After seeing a similar error in visual studios 2012 out of no where. I have found that that going to the root folder of the project and right clicking on it I unchecked read only and this error went away. Apparently TFS sometimes will made a folder read only. Hopefully this will help anyone with a similar issue. Thanks
This happened to me at VS 2010 and Win 7..
Case :
I can not Rebuild with Debug Configuration manager, but I can rebuild with Release Configuration manager
What I have tried:
Check my account type at control panel - user account --> My Account is Administrator
Set the bin folder not read only
Add security at bin folder to Everyone
stop the iis server
Stop antivirus, check ridiculous running program using task manager and ProcessExplorer
run VS as administrator
If All that way is still not working.
Then, the last way to try:
close solution
close visual studio
start - shutdown
press power button to turn on the computer
login to your account which has administrator previlege at user type
reopen solution
rebuild
that way working. All people call this way as Reset Computer
Mine got solved by:
Clean solution
Close all processes depending on VS (Current instances).
Rebuild
I had same problem, after read your answers , went to Task Manager and searched for app.exe because i believe maybe it doesn't close .
And found it , select it and do END TASK .my problem solved.
Before rebuild the solution, clear the project, stop the IIS and open the "bin" folder property. Uncheck the Read-only Attribute in general tab then rebuild.
I found that ending all msbuild.exe tasks (in Task Manager) fixed the issue with VS2012.
I struggeled with this since years.
I finally downloaded LockHunter to find out who locked the file.
In my case it was MBAM.
Once I added my project's directory to MBAMs exclusion list, I didn't have this problem anymore.
I too had the same issue. I resolved it
Closed my VS, then in Task Manager, End tasks like Microsoft VisualStudio WCF Tools, MSBuild.exe
Then open VS and clean and rebuild.
No matter what the cause of this problem is, the only working solution for me is the following:
Go to Your-Project-Properties -> Application tab(first tab) -> Change the Assembly name.
This way your app creates a new assembly file each time you change the assembly name.
Finally, after you finish to develop, you can delete all those extra assembly files and just keep the last one (main one). Non of the other solutions worked for me, except this one.
Run Visual Studio as Administrator
We recently experienced this on a WinPhone 8 project, in VS 2012 Update 2.
Inexplicably, the cause was using the Tuple type. Removing the code that used a Tuple the problem went away. Add the code back the problem returned.
This will Sound crazy, when ever i build the project the error will be displayed and the avast antivirus will show it as malicious attempt and the project does not run.i just simply disable my antivirus and build my solution again the missing .EXE file has been Created and the project has been successfully executed.
Or you can try this
Visual Studio build fails: unable to copy exe-file from obj\debug to bin\debug
I solved this by killing XDesProc which had a handle on the DLL it couldn't delete.
Well i have the same problem, my way to fix it was to stop and disable the "application experience" service in Windows.
Not a direct answer to your question..
One scenario when this can come is listed below -
If your application is under Debugging process - say by "Attach to Process" debugging, this error may come
If this error was encountered, you can proceed as the following
End the msbuild.exe task
End the explorer.exe task
Run the explorer.exe task again
for me it was the antivirus. Just add visual studio project or entire parent folder to Antivirus exclusion list or you can also add file extension as exclusion and this method worked for me in visual studio 2010/2012
Solution1:
Close the project.
Delete the bin folder.
Open the project.
Build the project.
Solution2:
Add the following code in pre-build event:
attrib -r $(OutDir)*..\* /s
This command line code will remove the ready-only attribute of "bin" folder. Now visual studio can easily delete and copy new dlls.
A very simple solution is to open the Task Manager (CTRL + ALT + DELETE), go to Processes tab and search by name the processes with your project name that are still running. Kill all the processes and go on ! :)
after day with search and build and rebuild i found that you just need to turn off turn on the visual studio its look like it catch the service in different thread
My Visual studio 2019 suddenly stops and restarts and then when i run project this error comes.
I resolve this issue by going into my project folder and delete bin and obj folder
Then clean and rebuild my project. This resolve my issue.