I have the following post build command in a VS project:
if '$(BuildingInsideVisualStudio)' == 'true' (
xcopy /Y /R /C "$(TargetPath)" "$(SolutionDir)common\bin"
)
The problem that I have is that the project is referenced from two separate solutions (meaning that for one it is not valid). My impression was that this should work anyway, because of the /C but that seems to not be the case.
My question is: what are the possibilities for getting around this? Basically, I just want this to work when it works and do nothing when it doesn't.
If $(SolutionDir) does not work for you, your have to use a path relative to $(ProjectDir), like $(ProjectDir)....\common.
Another alternative is an environment variable that must be set on a per-machine basis.
Related
We have several projects that have a "templates" folder that all get copied to the same "templates" folder in our shared bin directory. Intermittently we get xcopy failures.
C:\Program Files (x86)\MSBuild\12.0\bin\Microsoft.Common.CurrentVersion.targets(4429,5): error MSB3073: The command "xcopy /s /y /r "E:\Source\DotNet\Service Providers\ActionScheduler\Templates" "E:\Source\DotNet\bin\x64\Release\Service Providers..\Templates\"" exited with code 4
These are post build steps that are being run in devenv.
I'm wondering if anyone has a suggestion to reduce or remove these errors.
Perhaps there is an alternative to xcopy which is more robust?
All of the templates folders that get copied have a subfolder "EN" and some files under that directory.
Additional information:
<message>98> Sharing violation</message>
<message>98> 0 File(s) copied</message>
<message>98> Unable to create directory - E:\Source\DotNet\bin\x64\Release\Templates</message>
<message>98>C:\Program Files (x86)\MSBuild\12.0\bin\Microsoft.Common.CurrentVersion.targets(4429,5): error MSB3073: The command "xcopy /s /y /r "E:\Source\DotNet\Service Providers\ActionScheduler\Templates" "E:\Source\DotNet\bin\x64\Release\Service Providers\..\Templates\"" exited with code 4.</message>
The error still occurred after adding /d. I also tried pre-creating the folder in a prebuild step of a project that would get build earlier. But I still got the following error:
98> Sharing violation
98> Unable to create directory - E:\Source\DotNet\bin\x64\Release\Templates
98> 0 File(s) copied
98>C:\Program Files (x86)\MSBuild\12.0\bin\Microsoft.Common.CurrentVersion.targets(4429,5): error MSB3073: The command "xcopy /s /y /r /d "E:\Source\DotNet\Service Providers\ActionScheduler\Templates" "E:\Source\DotNet\bin\x64\Release\Service Providers\..\Templates\"" exited with code 4.
You'll need to look in the Output window for a diagnostic message from XCopy when this error occurs. "Intermittent" is pretty hard to explain without that diagnostic.
There is certainly a good way to greatly reduce the chances for this going wrong. You are copying these files over and over again for no good reason. Add the /D option, that only copies when a file does not yet exist or has changed. So you basically only copy these files once and about never again, can't fail that way :)
After edit: yeah, that sure looks like two post-builds trying to copy the same file at the same time. Unlucky timing, anti-malware has a knack for extending it too long while it scans the file. You need to fix that, one is enough. With very high odds that /D already fixes it.
Code 4 means:
"Initialization error occurred. There is not enough memory or disk space, or you entered an invalid drive name or invalid syntax on the command line."
Is E:\Source\DotNet\bin\x64\Release\Service Providers..\Templates\
OK? dotdot???
If you have several projects building the same output named support files you could try to turn off parallel builds. MSDN link for setting this option
However this looks like a system wide setting an not just for that project. As a last resort you could attempt to stop the copying of the files for all but one project by setting the "Copy to Output Directory" to "Do not copy".
I had a very similar issue, from the MSDN documentation here we added the following switches. Im my case the I switch seemed to do the trick.
Xcopy /Y /I /S
https://technet.microsoft.com/en-us/library/cc771254.aspx
I'm making a plugin framework and to aid development i am changing the output path of each plugin to the shell project. However, in doing so it breaks razor intellesense in any .cshtml files in that particular project.
Is there any way around this bug?
I set the output path back to default (\bin)
and set up a post build event
xcopy "$(ProjectDir)\bin" "$(SolutionDir)Frontline_UPF\Modules\$(ProjectName)" /i /s /y /q
I couldnt use $(TargetDir) since it added a \ to the end and that prevented xcopy from working.
I'm trying to get the output of git describe into my build as a preprocessor define, to use in versioning modules. Unfortunately, it's being a bit contrary (not sure where the issue is).
I had a pre-build event like:
for /f "delims=" %a in ('git describe') do set GITID=%a
which works from the command prompt, but returned code 255 in the build (which caused an error). So I changed it to:
git describe > buildprops_gitid.txt
set /p GITID= < buildprops_gitid.txt
which again, works in command prompt (and doesn't error during build). The file is created with the correct value.
In the preprocessor settings, I then have:
BUILD_TARGETFILE=$(TargetFileName)
BUILD_GITID=$(GITID)
The former works fine, putting the target filename into the file as expected. The latter doesn't work, instead putting an empty string. I suspect this is related to the env var being lost somewhere along the way.
Is there a way to get the output of CLI programs and use that as variables ($(var)) within Visual Studio?
the workaround i found for this was to generate an include file in a pre-build event.
something like the following version.bat script:
#echo off
FOR /F "tokens=*" %%i IN ('call git describe --always') DO echo #define VCSVERSION "%%i" > vcsversion.h
and then add #include "vcsversion.h" in the code.
this is basically the solution i suggested here
A few projects in my client's solution have a post-build event: xcopy the build output to a specific folder. This works fine when building locally. However, in TeamCity, I occasionally get
xcopy [...] exited with code 2
If I use regular copy, it exits with code 1. I expect this has something to do with file locks, although the specific files being copied are not the same, so perhaps just locking on the shared destination directory. I use /y to not prompt on overwriting files.
Why this fails in TeamCity but not locally?
Even if you provide the /Y switch with xcopy, you'll still get an error when xcopy doesn't know if the thing you are copying is a file or a directory. This error will appear as "exited with code 2". When you run the same xcopy at a command prompt, you'll see that xcopy is asking for a response of file or directory.
To resolve this issue with an automated build, you can echo in a pre-defined response with a pipe.
To say the thing you are copying is a file, echo in F:
echo F|xcopy /y ...
To say the thing you are copying is a directory, echo in D:
echo D|xcopy /y ...
Sometimes the above can be resolved by simply using a copy command instead of xcopy:
copy /y ...
However, if there are non-existent directories leading up to the final file destination, then an "exited with code 1" will occur.
Remember: use the /C switch and xcopy with caution.
I fixed the error code 2 by adding a \ at the end of my path, without it, xcopy will think that it is a file instead of a folder.
If you are using xcopy in a post build event use the /Y switch in addition to the /C.
/C Continues copying even if errors occur.
/Y Suppresses prompting to confirm you want to overwrite an existing file.
My fix for this issue was to go into the target bin folder, and ensure that the proper subfolder exists there. Once that subfolder was manually created, the build process completed successfully.
copy fixed it for me. xcopy with /c /y did not work. I was getting an exit 4 so I went with xcopy, but turned out I needed quotes around ($TargetPath).
My script:
if $(ConfigurationName) == Debug copy "$(TargetPath)" "$(SolutionDir)\Folder\bin\Debug\$(TargetFileName)"
Probably you using TeamCity with git. If yes, check that folders you want to copy are exists in git repository. Usually git aviod adding empty project folders to repository, so xcopy fails to find it and generates a error.
You can add some empty text file to empty folder, commit and see folder appears in repository.
I have a solution in VS2008 (C#) that contains multiple projects. I just retooled some of the .csproj files for our build process, and suddenly while coding Project B won't recognize references from Project A in the class code...think the red squiggly lines under a variable type I've created. However, building the solution generates no errors. Why's it behaving like this?
I would suggest that you clear your Visual Studio temp files - it can often get confused about project structures and require a fresh start.
First, quit out of VS completely and restart it. If the problem is still there, find your VS cache folder and delete it, and then do a rebuild.
For help finding your cache folder, check this post.
When VS starts acting strangely wonky, and I can't find a logical fix, I kill Visual Studio, and manually do a 'clean' by deleting all of the bin/obj folders.
I have a batch file that does this for me quicker than I could do it manually. I place this in my solution directory, and all my projects are found in subdirectories.
rem "%%~dpa" says: Give me the (d)drive and (p)path of the (a, %%a) file.
rem However, our dir /a:d will result in only listing folders...
rem The final "%%a" is just appending the 'file' (diretory name) to the
rem drive-and-path string
for /f %%a in ('dir /b /a:d *.*') do call :process "%%~dpa%%a"
pause
goto :eof
:process
echo Looking in %1
cd "%1"
if EXIST "%1\bin" (
echo Found 'bin' - it's gone now.
rd /s /q "%1\bin"
)
if EXIST "%1\obj" (
echo Found 'obj' - it's gone now.
rd /s /q "%1\obj"
)
cd ..
Another solution
If the other answers regarding clearing Visual Studio cache, .NET Cache, and
ensuring references are valid don't work, try this one.
Based on the source, and trying this solution, I've had success.
Deleting the visual studio solution cache folder
Close out of all instances of visual studio
Locate the .vs hidden folder within your solution.
Delete the entire hidden .vs folder.
Rebuild the solution
-- Source
In your Project Properties from B, make sure Project A is checked under dependencies.
Make sure both projects are being built in the Configuration Manager
(right click on the solution and then click “Configuration Manager”)
You might also hover over the redline or just build again to see if you get anymore details. C# and VB are both pretty good at telling you why they not happy.
I've removed the reference from the project which classes were not recognized and re-added this reference. Everything got fixed.
Double check that you made the classes you are referencing public. Visual Studio doesn't do it automatically when you make a new class and I sometimes forget.