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.
Related
I have a post-build event set in Visual Studio 2022 for a number of projects to copy the built assembly to a common library location. It was working just fine until I switched the TargetFramework to .Net6.0. After several trials and tests I've narrowed the problem down to the use of $(TargetName) in the xcopy statement:
xcopy /Y "$(TargetDir)$(TargetName).*" "$(SolutionDir)\..\Common\"
I've had a pre-build event echo the values of $(TargetDir), $(TargetName) and $(SolutionDir) to the Output window to check their values -and all is well, they are correct. The only way I can get this xcopy to work right now is to drop $(TargetName) and replace it with the actual assembly name for each project:
xcopy /Y "$(TargetDir)MyAssemblyName.*" "$(SolutionDir)\..\Common\"
I really don't want to have to do this for every single project in the solution so has anyone seen or had this problem?
If I leave the xcopy statement as it was originally I get 0 files copied.
I am using prebuild event commands to delete certain folders in my wwwroot directory.
Now, I need to do that for certain dll's in the bin folder that follow a certain naming convention like,
Foundation.*.dll
Currently, I am using the following to delete a directory:
rd /s /q "C:\inetpub\wwwroot\siteroot.local\App_Config\Include\zzz.Project"
I need a variation on this to delete just certain dlls.
del /s /q "C:\inetpub\wwwroot\sc.vitas-p.local\bin\Project.*.*"
This wound up being the answer.
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
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 DLL project for Visual Studio 2005 that has "XML documetation file" turned on.
Whenever I do an incremental build, during post-build event execution there is no XML documentation file in the output directory.
If I pause the build during post-build event (using sleep utility from GnuWin32 CoreUtils), I can see the file in the output directory with a name like vs5BB5.tmp. But this file is not renamed to MyLib.xml until post-build event (and "AfterBuild" target, as I have some customizations there) are finished.
For a clean build in Studio and for MSBuild started from a command line everything works as expected - XML documentation file is created before post-build events.
Why this happens, and how do I fix incremental builds?
Was just having the same issue. This is a known problem with Visual Studio and incremental builds. See this post on microsoft connect.
I solved it with a conditional xcopy like the one below:
if exist "$(TargetDir)$(TargetName).xml" xcopy $(TargetDir)$(TargetName).xml $(ProjectDir)......\bin\ /C /I /R /Y
SF
Just having this problem myself....
what I found is that the xml file is named a .tmp file, so you can copy this tmp file to where you want, its just a bit of a "messy" work around.
I'm also quite tempted to write myself a command line tool thats called something like :-
WaitForThenCopy <source path> <target path> <milliseconds to wait>
only problem is it would have to be non blocking and you wouldn't know if it worked or not.
I'm using a simple batch file to do the copying instead of the default copy command that detects the tmp file and copies/renames this instead.
REM There is a bug in VS where the xml documentation is written to a tmp file
REM during incremental builds, preventing access during post-build events.
REM See http://connect.microsoft.com/VisualStudio/feedback/details/470485/strange-file-not-found-error-xml-documentation-file-renamed-during-incremental-build
REM As a work around for following script tries to catch this situation and copys/remanes
REM this tmp-file instead.
REM .SYNOPSIS
REM CopyXmlDocumentation "X:\path\to\source.xml" "Y:\target\dir"
if exist "%~1%" (
REM if the file exists, copy it as-is
copy /Y "%~1" "%~2"
) else (
REM else we try to copy the .tmp file and rename it to the desired target name
REM we assume that the tmp file is named "vsXXXX.tmp" where XXXX is an arbitrary string
copy /Y "%~d1\%~p1\vs*.tmp" "%~2\%~n1%~x1"
)