I have a file in a folder of my C# VS2010 project marked Content and Always Copy.
When I change this file and save it, externally to VS, and then run the project, the modified file is not copied to the output. If I rebuild, then it is. My guess is that VS does not use the modified date time stamp of the file to determine whether it should be copied or not.
Am I missing something? It's driving me nuts as I'm losing 5 minutes per run.
Thank you!
Hard to explain so start by getting better diagnostics. Tools + Options, Projects and Solutions, Build and Run settings. Change the "MSBuild project build output verbosity" setting to Normal. In that same property page, ensure that the "On Run, when projects are out of date" setting is set to Always build. Look in the Output window when you press F5 or Build + Build, the _CopyOutOfDateSourceItemsToOutputDirectory task is the one that copies the file.
One possible trap when you use Project + Add Existing Item: the IDE makes a copy of the file that you selected. You might be changing the original file instead of the copy in the project directory. You'd fix that by clicking the arrow on the Add button in the dialog and selecting "Add As Link".
The behavior you are expecting can be achieved by changing the Build Action from "Content" to "Embedded Resource".
Came across this when I needed to use COMFileReference but also needed to copy the DLL to the output folder.
In the end, ending up adding the DLL twice to the project, once as Content for the copy to output folder and once as COMFileReference. Easiest way I found was to modify the .csproj xml directly.
Related
I'm forced to work with a tool that generates it's own solution files (.sln). The tool is building the solution based on whatever files that end with .cs. The problem is that you can't change files properties as the solution gets regenerated each time you rebuild. This means that you can't set files to always copy in Visual Studio, as it will be reset the next rebuild.
After looking online for a while I was wondering, is there a way to reference files as always copy with C# tags?
For example... Reference.cs
[assembly: AlwaysCopyToOutputDirectory("path/to/my/file.xml")]
Is there a tag like this that I can include in my code in order to change the file properties automatically?
I changed the Output path for some projects of my Solution and now I´m getting some errors when I Build my solution. Errors like:
Could not copy the file "MyProject....pdb" because it was not found...
How could I fix it?
(1) Please Uncheck the option "Enable the Visual Studio hosting process" from the project property->debug tab and see if that solves your issue.
(2) Please check your previous output and current output path, whether you can get the pdb file in the two folders? I suggest you delete the previous output path like bin/debug or release, and then re-open the project file, clean and rebuild the solution with the new output path, check it again.
(3) I also met this kind of issue which was related to the post-build event, so you need to check it in your side.
(4) Of course, if it is the reference between different projects, please make sure that you add the correct path for this reference and set the "copy local=true" after you change the output path.
After changing something in my C# code, I can run it without problem. However, if I run the .exe file in WindowsFormsApplication1/bin/Debug/, I would get an error message. By checking the 'Date modified' of this .exe file, I found it wouldn't update accordingly.
I then tried to do Build/Build Solution and Rebuild Solution but the .exe file would still not be updated.
Can you tell me how to update the .exe file?
To view the output directory for your builds, right-click on the project you are trying to build and select "Properties". Under the "Build" tab you should find the following:
At the top you can also see the configuration under which your project is building (usually Debug or Release). By default, the output directory for Debug and Release builds are, respectively, "bin\Debug" and "bin\Release". EDIT: To change which build configuration is currently active, you will need to go to Build -> Configuration Manager:
Once you have checked the build directory paths and the configuration which you are building, do a Clean Solution followed by a Build Solution and your *.exe file should now be the latest version.
Hope this helps!
Alex
EDIT:
Apologies - meant also to mention that the build directory paths are relative to the project directory (the directory where the *.csproj file for your project lives). So updating the *.exe file in WindowsFormsApplication1\bin\Debug under Debug configuration with the default output directory is contingent upon WindowsFormsApplication1.csproj being contained in the WindowsFormsApplication1 directory.
Somehow I figured out why it is happening. If you have multiple projects in a solution (I assume that's the case above), check the status of "Build" checkbox in the property pages. I faced same issue when one of my three projects under solution was not refreshing whenever I rebuild the solution.
Hope this will help!
I'm trying to publish project (tools vs2010), but cannot all the time getting the error below.
I paste to my projects files from another project and then I changed namespace (OldProjectName) to the parent project (NewProjectName). But it still getting information from somewhere about old project.
I cleaned solution, builded, rebuilded. Closed and reopened again and all the time the same error.
I'm able to build project but publish it.
Any ideas what can cause the problem?
Error 1 Copying file
obj\Debug\OldProjectName.csproj.FileListAbsolute.txt to
obj\Debug\Package\PackageTmp\obj\Debug\OldProjectName.csproj.FileListAbsolute.txt
failed. Could not find file
'obj\Debug\OldProjectName.csproj.FileListAbsolute.txt'. 0 0 NewProjectName
Open your .csproj file in notepad
Find "obj\Debug\OldProjectName.csproj.FileListAbsolute.txt"
Remove that line and save it
Open your project and try to publish it and this time you will be succeeded.
Note: if you are getting any more file like .pdb remove that as well.
Hope it will help you
Make sure the obj folder is not read only, if so change read only property of this folder to false. this worked for me.
Check the permissions to the folder obj\Debug\ if you give it write permissions, the error would go away.
Check if the folders "bin" and "obj" are checked-in to source control, if so delete those two folders in source control. There is no need to check-in these two folders to source folders. Also make sure that these folders "obj" and "bin" are deleted from your hard disk, they will be created again after a build.
Hope this will fix your issue.
It is your responsibility to make copies so you can go back to one.
Open your project file (vb/cs)proj with a notepad, and search for the missing files.
In my case I got this error when I tried to publish the project and certain files were not found.
Each publish attempt I got another file name, after checking that the file actually didn't exist in the project, I removed it from the project file, manually.
Then publish succeeded.
Delete the obj folder and build again.
Ref: http://forums.asp.net/t/1402005.aspx
Like many others these files were read only and needed to be deleted or actually able to be overwritten by VS. However, as may be the case for many others, the problem was because these files were checked in to source control. Your bin and obj folders should not be in source control. Mark them for delete and submit the changelist.
One exception to the rule is for the bin folder could be dll files that are not .Net compatible. Such as a C/C++ dll that you are using through a .Net wrapper dll. I mark them as content so that they get published and check them into source control.
I too had this problem. I resolved this by deleting files inside project bin folder (.dll and .pdb) and closed and re-opened VS .
The file named FileListAbsolute.txt was deleted from the folder obj/debug. Visual Studio can automatically recreate the file and others in the obj/debug for you.
For VS to recreate it, set the configuration of the solution and the project to debug mode. Then rebuild your solution.
To change the configuration mode to debug, from the solution explorer, right-click on the solution name and select Properties.
Select Configuration under Configuration Properties. Then select Debug from the dropdown list.
Click Apply and OK. Ensure that in Configuration Manager, the configuration mode is also a debug mode.
Then rebuild your solution.
For me using solution here: Certain Razor views not publishing
Excluding the views folder and re-including fixed it for me. So it's possible for anyone else experiencing this it may be as simple as excluding and then including the file/folder in question of your project.
I encountered this bug using VS2017 with a solution stored in OneDrive.I suspected OneDrive's sync mechanism to be the root cause of this.
When I tried to reproduce using VS2019 however it did not reappear. Looks solved in between these versions.
I don't see it in the .sln file, which is what I expected.
Which project is the "startup" project only has any relevance for debugging, which means it's user metadata from the point of the solution and the projects. Regardless of which project is the "startup" project, the compiled code is the same.
Because of this, the information is stored as a user setting in the Solution User Options file (solution.suo) which accompanies the Solution file (solution.sln). The .suo file "Records all of the options that you might associate with your solution so that each time you open it, it includes customizations that you have made" according to MSDN.
The .suo file is a binary file. If you want to read or change it programatically, you have to use IVsPersistSolutionOpts.LoadUserOptions from the Microsoft.VisualStudio.Shell.Interop namespace.
It's in the Solutions User Options (.suo) file, which gets created next to the .sln file.
It seems that the first item in the solution's sln file is, by default, the startup project. So, you could manually edit the sln file to make your project the first project in the solution. Then, a user can override that by selecting a different project to be startup.