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.
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
Lets say I have a project solution, I want to copy the contents of bin/Release folder after the build into another folder named "Deploy"
Source: D:\Solution\bin\Release
Destination: D:\Destinationfolder\bin\deploy
the macros are as follows
TargetDir : D:\Solution\bin\Release
ProjectDir: D:\Solution
I have tried this
xcopy /? $(TargetDir) $(ProjectDir)\..\Bin\Deploy /R /Y /S
This is not working. Am I doing anything wrong? Is there any other way to do this?
Remove the /? from the xcopy command, and add quotes around paths. The .. will take the $(ProjectDir) path back to D:, so the Destinationfolder should also be added.
So: xcopy "$(TargetDir)" "$(ProjectDir)\..\Destinationfolder\Bin\Deploy" /R /Y /S
I would suggest you to create a Publish Profile. If you want to build the project to a desired folder you can simply right click on the project and click Publish.
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.
strange 1 here..
have a solution with multiple projects in (mvc2 application, class library etc).
the solution will not build in debug mode anymore. 1 if the projects isnt building its DLL anymore (although it creates reference dll's in the bin\debug folder).
this gives me the error: Metadata file 'C:[solution]\bin\Debug[myprojectname].dll' could not be found.
if i put the build into release, all my dll's build and solution correctly loads.
any idea why this is happening?
thanks
Check Build - Configuration Manager.
For each project in your solution you can check if it should be build and some more things.
I found that sometimes a project just got unchecked so it wont build,....
If you have lots of Metadata errors in build output, there is usually one compilation error way at the bottom of the list. Do you have any compiler directives in your code (like #ifdef DEBUG that would be causing problems?
Sometimes VS gets confused and I have to go manually clean the bin folders for it to recompile. I usually create a batch file and put it in the root of my solution to do this for me.
Clean.bat:
FOR /F "tokens=*" %%G IN ('DIR /B /AD /S bin') DO RMDIR /S /Q "%%G"
FOR /F "tokens=*" %%G IN ('DIR /B /AD /S obj') DO RMDIR /S /Q "%%G"
I run this whenever VS starts misbehaving. If that doesn't work then it's time for a reboot.
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.