We Keep Coding

Opentap Could not copy "[name].dll" to "bin\Debug\Dependencies\[Name].dll". Exceeded retry count of 10. Failed

Maybe someone of you can help me by my problem. At first to make clear this problem is a known problem on stackoverflow and I read all the solutions for that problem and tried them out but this do not solved my problem.
Problem:
MSB3027: Could not copy
"C:\Users\SpecificUser.nuget\packages\opentap\9.10.4\build\payload\Dependencies\System.Runtime.InteropServices.RuntimeInformation.4.0.2.0\System.Runtime.InteropServices.RuntimeInformation.dll"
to
"bin\Debug\Dependencies\System.Runtime.InteropServices.RuntimeInformation.4.0.2.0\System.Runtime.InteropServices.RuntimeInformation.dll".
Exceeded retry count of 10. Failed.
Due to that error I can't build my solution no matter if I build in debug mode or release mode.
Try to Solve
At first I simply tried to clean the project and rebuild it
I also tried to clean the solution and rebuild the solution
At next I unloaded the project and reloaded it with and without dependencies
Than I tried to close VS2019 and reopened the project in combination with the previous parts
After that I tried to uncheck "allows NuGet to automatically check for missing packages during
build in Visual Studio" (Debug -> options)
Than I tried to build the project with all combinations of above
Than I tried the same but with Clear All NuGet Cache(s)
Than I tried to insert a prebuild action
if exist "$(TargetPath).locked" del "$(TargetPath).locked"
if not exist "$(TargetPath).locked" move "$(TargetPath)" "$(TargetPath).locked"
This throw me an error MSB3073 but without an error message and the description says:
MSB3073: The command "if exist "C:\Users\SpecificUser\source\repos\ProjectName\bin\Debug\ProjectName.dll.locked" del "C:\Users\SpecificUser\source\repos\ProjectName\bin\Debug\ProjectName.dll.locked"
Also, I made sure that the output path is clear
At next I tried to delete the bin folder and the obj folder.
All tis step have no success.
Additional Problem
Sometimes the dependencies would not load. For that I tried to reinstall them or reload the dependencies. Sometimes it works but usually not. Also, some References such as OpenTAP or Microsoft.CSharp has a yellow rectangular inside the symbol
yellow rectangular at reference
Used Recourses
OpenTAP SDK
OpenTAP lib
NetStandard lib
Microsoft.CSharp lib
Tried Solutions from StackOverflow
Could not copy "obj\Debug{project}.dll" to "bin{project}.dll"
visual studio 2013 Could not copy "obj\Debug.dll" to "bin\Debug.dll"
Error: Cannot access file bin/Debug/... because it is being used by another process
Unable to Copy File "*\bin\debug*.dll" to "bin*.dll" in Visual Studio
Error MSB3027: Could not copy "C:\pagefile.sys" to "bin\roslyn\pagefile.sys". Exceeded retry count of 10. Failed
Maybe someone can help me with my issue \^o^/

Just for everyone who is interested what is the solution.
The problem with I hade was, that Visual Studio has problems to solve the dependencies. Due to an test I tried to recreate an project on the same path and moved the old project to my desktop. Than to look at the code I opened the old project and after that it worked.
Solution
Visual Studio is not able to solve the dependencies when the path is to long. Now I have changed the path and it works.

how to install GDAL into visual studio for c# on windows?

I'm gonna use GDAL into visual studio for c# on windows.
And followed some steps through some posts.
However, it seems it doesn't work between steps and, the biggest problem is that it can't build and install.
I will explain how to install, then if any of you knows and let me know why i can't install it, it will be so helpful.
to download:
Stable Releases, GDAL2.1.2 and MapServer 7.0.2, MSVC 2013/x64(mine:64), gdal-201-1800-x64-core.msi.
link: http://www.gisinternals.com/query.html?content=filelist&file=release-1800-x64-gdal-2-1-2-mapserver-7-0-2.zip
to set up paths:
System -> Advanced system settings -> System Properties -> Environment Variables =>
Edit System Variable: Path, C:\Program Files\GDAL\csharp
Add System Variable: GDAL, C:\Program Files\GDAL
(i also add two more: C:\Program Files\GDAL\gdalplugins, C:\Program Files\GDAL\gdal-data with names)
I downloaded a sample to test this environment setting.
(http://svn.osgeo.org/gdal/trunk/gdal/swig/csharp/apps/GDALInfo.cs)
(visual studio 2013)Add four of the dll-files(gdal_csharp.dll, gdalconst_csharp.dll, ogr_csharp.dll and osr_csharp.) to my project references from C:\Program Files\GDAL\csharp(there was no gdalconst_cshap.dell though, i download it from a site i found).
Change Platform target to x64 in Properties.
Run the program.
1) nothing happened.
2) in the case, i forced to change the running goes to Gdal.AllRegister() to chech if GADL and VS are linked though, it said "The type initializer for 'OSGeo.GDAL.GdalPINVOKE' threw an exception."
// I know there must be something i missed during process, but i think for now i can't find anymore. any help or hints or suggestion will be very welcomed!

TFSBuild 2013 unable to change msbuild version

I have a TFSBuild 2013 server that we are trying to now build UWP projects with, but we cannot seem to make it use the correct MSBuild version.
Symptoms:
When building the UWP projects, we get lots of errors like this:
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\AppxPackage\Microsoft.AppXPackage.Targets (283): A numeric comparison was attempted on "10.0.11000.0" that evaluates to "10.0.11000.0" instead of a number, in condition "'$(TargetPlatformVersion)' >= '10.0.11000.0'".
Many reports abound for this error, all telling you to ensure that TFS Build is using the correct version of the MSBuild. And herein lies the issue. We cannot seem to make the build server use the correct version.
Here is what we have tried (build definitions are using TfvcTemplate.12.xaml template):
Installing 2015 build tools (update 3) on the build server
Installing VS2015 on the build server (Yuck)
Various combinations of MSBuild parameters in the build definition. (/tv:14.0 & /p:VisualStudioVersion=14.0)
Inclusion of Microsoft.Net.Compilers nuget package
Editing the TfvcTemplate.12.xaml template and setting "Run MSBuild" step to set "ToolsVersion" to "14.0". (Note, there is no "ToolsPath" setting in this version of the template, so I cant do that).
Setting ToolsVersion="14.0" in every .csproj file
No matter what we change, we cannot get the Build Agent to use the 14.0 version of MSBuild.
Strangely, nuget seems to find the correct version when doing the package restore. In the logs we see this when running the nuget.exe restore command: MSBuild auto-detection: using msbuild version '14.0' from 'C:\Program Files (x86)\MSBuild\14.0\bin'.
But further down in the logs, where all the errors start we see this (note: wrong tools version):
C:\Program Files (x86)\MSBuild\12.0\bin\MSBuild.exe /nologo /noconsolelogger "C:\Builds..." [SNIP]
Any help or suggestions gratefully received - I'm at my wits end :)

I finally gave up trying to make this behave with configuration, but managed to get this working on the build machine by hacking the registry.
I changed the following registry keys:
HKLM\SOFTWARE\Wow6432Node\Microsoft\MSBuild\12.0\MSBuildOverrideTasksPath
HKLM\SOFTWARE\Wow6432Node\Microsoft\MSBuild\ToolsVersions\12.0\MSBuildToolsPath
In both cases, I changed the value
from:
C:\Program Files (x86)\MSBuild\12.0\bin\
to:
C:\Program Files (x86)\MSBuild\14.0\bin\
Disclaimer: I don't know what other affects this will have, but its got our builds using the correct MSBuild version, and is limited in scope to the build server.

Editing the TfvcTemplate.12.xaml template and setting "Run MSBuild" step to set "ToolsVersion" to "14.0".
This will work if you also add the following piece in the MSBuild 12.0 config file (as described here)
<msbuildToolsets>
<toolset toolsVersion="14.0">
<property name="MSBuildToolsPath" value="C:\Program Files (x86)\MSBuild\14.0\Bin\" />
</toolset>
</msbuildToolsets>
Please note there is also amd64 folder in the MSbuild\bin directory which has its own config file

Using msbuild to execute a File System Publish Profile

I have a c# .Net 4.0 project created with VS2010 and now being accessed with VS2012.
I'm trying to publish only the needed files from this website to a destination location (C:\builds\MyProject[Files])
My file structure:
./ProjectRoot/MyProject.csproj
./ProjectRoot/Properties/PublishProfiles/FileSystemDebug.pubxml
I'm running the following via MSBuild:
C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe ./ProjectRoot/MyProject.csproj /p:DeployOnBuild=true /p:PublishProfile=./ProjectRoot/Properties/PublishProfiles/FileSystemDebug.pubxml
Here's the xml in FileSystemDebug.pubxml
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<WebPublishMethod>FileSystem</WebPublishMethod>
<LastUsedBuildConfiguration>Release</LastUsedBuildConfiguration>
<LastUsedPlatform>Any CPU</LastUsedPlatform>
<SiteUrlToLaunchAfterPublish />
<ExcludeApp_Data>False</ExcludeApp_Data>
<publishUrl>C:\builds\MyProject\</publishUrl>
<DeleteExistingFiles>True</DeleteExistingFiles>
</PropertyGroup>
</Project>
The resulting behavior is:
a zip file is created here:./ProjectRoot/obj/Debug/Package/MyProject.zip
Nothing is deployed to <publishUrl>C:\builds\MyProject\</publishUrl> WTF
the zip file that is created is a pigs breakfast and full of files that aren't needed for the application.
When I run this publish profile through visual studio a folder is created at *C:\builds\MyProject* and contains the exact artifacts that I want.
How do I get this simple result from msbuild?

FYI: I had the same issue with Visual Studio 2015. After many of hours trying, I can now do msbuild myproject.csproj /p:DeployOnBuild=true /p:PublishProfile=myprofile.
I had to edit my .csproj file to get it working. It contained a line like this:
<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets"
Condition="false" />
I changed this line as follows:
<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v14.0\WebApplications\Microsoft.WebApplication.targets" />
(I changed 10.0 to 14.0, not sure whether this was necessary. But I definitely had to remove the condition part.)

Found the answer here:
http://www.digitallycreated.net/Blog/59/locally-publishing-a-vs2010-asp.net-web-application-using-msbuild
Visual Studio 2010 has great new Web Application Project publishing
features that allow you to easy publish your web app project with a
click of a button. Behind the scenes the Web.config transformation and
package building is done by a massive MSBuild script that’s imported
into your project file (found at: C:\Program Files
(x86)\MSBuild\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.targets).
Unfortunately, the script is hugely complicated, messy and
undocumented (other then some oft-badly spelled and mostly useless
comments in the file). A big flowchart of that file and some
documentation about how to hook into it would be nice, but seems to be
sadly lacking (or at least I can’t find it).
Unfortunately, this means performing publishing via the command line
is much more opaque than it needs to be. I was surprised by the lack
of documentation in this area, because these days many shops use a
continuous integration server and some even do automated deployment
(which the VS2010 publishing features could help a lot with), so I
would have thought that enabling this (easily!) would be have been a
fairly main requirement for the feature.
Anyway, after digging through the Microsoft.Web.Publishing.targets
file for hours and banging my head against the trial and error wall,
I’ve managed to figure out how Visual Studio seems to perform its
magic one click “Publish to File System” and “Build Deployment
Package” features. I’ll be getting into a bit of MSBuild scripting, so
if you’re not familiar with MSBuild I suggest you check out this crash
course MSDN page.
Publish to File System
The VS2010 Publish To File System Dialog Publish to File System took
me a while to nut out because I expected some sensible use of MSBuild
to be occurring. Instead, VS2010 does something quite weird: it calls
on MSBuild to perform a sort of half-deploy that prepares the web
app’s files in your project’s obj folder, then it seems to do a manual
copy of those files (ie. outside of MSBuild) into your target publish
folder. This is really whack behaviour because MSBuild is designed to
copy files around (and other build-related things), so it’d make sense
if the whole process was just one MSBuild target that VS2010 called
on, not a target then a manual copy.
This means that doing this via MSBuild on the command-line isn’t as
simple as invoking your project file with a particular target and
setting some properties. You’ll need to do what VS2010 ought to have
done: create a target yourself that performs the half-deploy then
copies the results to the target folder. To edit your project file,
right click on the project in VS2010 and click Unload Project, then
right click again and click Edit. Scroll down until you find the
Import element that imports the web application targets
(Microsoft.WebApplication.targets; this file itself imports the
Microsoft.Web.Publishing.targets file mentioned earlier). Underneath
this line we’ll add our new target, called PublishToFileSystem:
<Target Name="PublishToFileSystem"
DependsOnTargets="PipelinePreDeployCopyAllFilesToOneFolder">
<Error Condition="'$(PublishDestination)'==''"
Text="The PublishDestination property must be set to the intended publishing destination." />
<MakeDir Condition="!Exists($(PublishDestination))"
Directories="$(PublishDestination)" />
<ItemGroup>
<PublishFiles Include="$(_PackageTempDir)\**\*.*" />
</ItemGroup>
<Copy SourceFiles="#(PublishFiles)"
DestinationFiles="#(PublishFiles->'$(PublishDestination)\%(RecursiveDir)%(Filename)%(Extension)')"
SkipUnchangedFiles="True" />
</Target>
This target depends on the
PipelinePreDeployCopyAllFilesToOneFolder target, which is what VS2010
calls before it does its manual copy. Some digging around in
Microsoft.Web.Publishing.targets shows that calling this target causes
the project files to be placed into the directory specified by the
property _PackageTempDir.
The first task we call in our target is the Error task, upon which
we’ve placed a condition that ensures that the task only happens if
the PublishDestination property hasn’t been set. This will catch you
and error out the build in case you’ve forgotten to specify the
PublishDestination property. We then call the MakeDir task to create
that PublishDestination directory if it doesn’t already exist.
We then define an Item called PublishFiles that represents all the
files found under the _PackageTempDir folder. The Copy task is then
called which copies all those files to the Publish Destination folder.
The DestinationFiles attribute on the Copy element is a bit complex;
it performs a transform of the items and converts their paths to new
paths rooted at the PublishDestination folder (check out Well-Known
Item Metadata to see what those %()s mean).
To call this target from the command-line we can now simply perform
this command (obviously changing the project file name and properties
to suit you):
msbuild Website.csproj "/p:Platform=AnyCPU;Configuration=Release;PublishDestination=F:\Temp\Publish" /t:PublishToFileSystem

Still had trouble after trying all of the answers above (I use Visual Studio 2013). Nothing was copied to the publish folder.
The catch was that if I run MSBuild with an individual project instead of a solution, I have to put an additional parameter that specifies Visual Studio version:
/p:VisualStudioVersion=12.0
12.0 is for VS2013, replace with the version you use. Once I added this parameter, it just worked.
The complete command line looks like this:
MSBuild C:\PathToMyProject\MyProject.csproj /p:DeployOnBuild=true /p:PublishProfile=MyPublishProfile /p:VisualStudioVersion=12.0
I've found it here:
http://www.asp.net/mvc/overview/deployment/visual-studio-web-deployment/command-line-deployment
They state:
If you specify an individual project instead of a solution, you have to add a parameter that specifies the Visual Studio version.

It looks to me like your publish profile is not being used, and doing some default packaging. The Microsoft Web Publish targets do all what you are doing above, it selects the correct targets based on the config.
I got mine to work no problem from TeamCity MSBuild step, but I did specify an explicit path to the profile, you just have to call it by name with no .pubxml (e.g. FileSystemDebug). It will be found so long as in the standard folder, which yours is.
Example:
C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe ./ProjectRoot/MyProject.csproj /p:DeployOnBuild=true /p:PublishProfile=FileSystemDebug
Note this was done using the Visual Studio 2012 versions of the Microsoft Web Publish targets, normally located at "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\Web". Check out the deploy folder for the specific deployment types targets that are used

Actually I merged all your answers to my own solution how to solve the above problem:
I create the pubxml file according my needs
Then I copy all the parameters from pubxml file to my own list of parameters "/p:foo=bar" for msbuild.exe
I throw away the pubxml file
The result is like that:
msbuild /t:restore /t:build /p:WebPublishMethod=FileSystem /p:publishUrl=C:\builds\MyProject\ /p:DeleteExistingFiles=True /p:LastUsedPlatform="Any CPU" /p:Configuration=Release

FYI: Same problem with running on a build server (Jenkins with msbuild 15 installed, driven from VS 2017 on a .NET Core 2.1 web project).
In my case it was the use of the "publish" target with msbuild that ignored the profile.
So my msbuild command started with:
msbuild /t:restore;build;publish
This correctly triggerred the publish process, but no combination or variation of "/p:PublishProfile=FolderProfile" ever worked to select the profile I wanted to use ("FolderProfile").
When I stopped using the publish target:
msbuild /t:restore;build /p:DeployOnBuild=true /p:PublishProfile=FolderProfile
I (foolishly) thought that it would make no difference, but as soon as I used the DeployOnBuild switch it correctly picked up the profile.

First check the Visual studio version of the developer PC which can publish the solution(project).
as shown is for VS 2013
/p:VisualStudioVersion=12.0
add the above command line to specify what kind of a visual studio version should build the project. As previous answers, this might happen when we are trying to publish only one project, not the whole solution.
So the complete code would be something like this
"C:\Windows\Microsoft.NET\Framework\v4.0.30319\msbuild.exe" "C:\Program Files (x86)\Jenkins\workspace\Jenkinssecondsample\MVCSampleJenkins\MVCSampleJenkins.csproj" /T:Build;Package /p:Configuration=DEBUG /p:OutputPath="obj\DEBUG" /p:DeployIisAppPath="Default Web Site/jenkinsdemoapp" /p:VisualStudioVersion=12.0

Run from the project folder
msbuild /p:DeployOnBuild=true /p:PublishProfile="release-file.pubxml" /p:AspnetMergePath="C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.8 Tools" /p:Configuration=Release
This takes care of web.config Transform and AspnetMergePath

Migrating Visual Studio 2005 sln to 2008, warning with vc98 paths in LIB environment variable, how to fix?

I'm migrating a solution from visual studio 2005 to visual studio 2008. When I build the solution in 2005, I don't have any issues. However, after I use devenv.exe /Upgrade and then use msbuild on the solution, I get the following warnings:
CSC : warning CS1668: Invalid search path '\vc98\lib' specified in 'LIB environment variable' -- 'The system cannot find the path specified.'
CSC : warning CS1668: Invalid search path '\vc98\mfc\lib' specified in 'LIB environment variable' -- 'The system cannot find the path specified. '
CSC : warning CS1668: Invalid search path 'c:\program files\microsoft visual studio 9.0\vc\platformsdk\lib' specified in 'LIB environment variable' -- 'The system cannot find the path specified.'
I have checked http://social.msdn.microsoft.com/Forums/en-US/Vsexpressinstall/thread/3f875480-fee2-4bc3-b829-95e220b22a01 and it doesn't offer me any help because my LIB and INCLUDE environment variables are not set either in the user vars or the system vars. I've looked at Studio's Tools > Options > Projects and Solutions> VC++ Directories and there's nothing that references anything old:
Library Files:
$(VCInstallDir)lib
$(VCInstallDir)atlmfc\lib
$(VCInstallDir)atlmfc\lib\i386
$(WindowsSdkDir)\lib
$(FrameworkSDKDir)lib
$(VSInstallDir)
$(VSInstallDir)lib
Include files:
$(VCInstallDir)include
$(VCInstallDir)atlmfc\include
$(WindowsSdkDir)include
$(FrameworkSDKDir)include
I used diagnostic output so that I could see exactly what the LIB variable includes when being called:
lib = c:\Program Files\Microsoft Visual Studio 9.0\VC\ATLMFC\LIB;c:\Program Files\Microsoft Visual Studio 9.0\VC\LIB;C:\Program Files\Microsoft SDKs\Windows\v6.0A\lib;\vc98\lib;\vc98\mfc\lib;c:\program files\microsoft visual studio 9.0\vc\platformsdk\lib;c:\program files\microsoft visual studio 9.0\vc\lib;c:\program files\microsoft visual studio 9.0\vc\atlmfc\lib;
LIBPATH = c:\Windows\Microsoft.NET\Framework\v3.5;c:\Windows\Microsoft.NET\Framework\v2.0.50727;c:\Program Files\Microsoft Visual Studio 9.0\VC\ATLMFC\LIB;c:\Program Files\Microsoft Visual Studio 9.0\VC\LIB
So if that vc98 is NOT in my env vars, or my studio settings and vc98 isn't even installed (nor the redist), where is that path coming from? What process sets up the LIB env var like that?

Found on MSDN:
Yes this is a known issue that occurs
to some people. Look carefully in
your LIB path. Right after ATLMFC, V,
SDK -> \vc98\lib. Delete this entry
(and the one that follows). If the
LIB is a user variable then you'll
need to restart VS or perhaps log off
and back on. If it is a system
variable then you'll have to reboot.
Your error should then go away.

Here is the solution
http://msdn.microsoft.com/en-us/library/tcbs315h(v=vs.80).aspx
its refer to the LIB entry at Environment Variables

Seems like you have covered most things here, so the only thing I can think of is inherited property sheets.
They are specified in the vcproj XML (or you can check the Property Manager in the IDE):
<VisualStudioProject>
<Configurations>
<Configuration InheritedPropertySheets="stuff.vsprops">...
If you do have some inherited property sheets, go have a look in the file and see if you have any vc98 lib paths set explicitly?

I am wondering if this could be due to the change in using the compiler switches /MT and /MTd from /ML and /MLd which occured for VS2005 relating to C runtime libraries?
Refer to here and see if it helps:
http://msdn.microsoft.com/en-us/library/abx4dbyh.aspx

I'm having a very similar issue with C# projects in VS.NET2010. It appears only to affect those projects which import C++/CLI projects. The projects are still set to compile using the v9.0 toolset(C++, C++/CLI) and .NET 3.5 (C++/CLI, C#). Have you had any luck finding the source of the problem?
I worked around it by adding warning 1668 to the ignored warnings list in the properties of the affected projects. That's not ideal, but better than spam in my warnings list.