After reinstal win 10 I installed VS 2019 (used VS 2013 before). All is running well, only one project with svc service I can't debug using WcfTextClient. Build is OK, but when the WcfTestClient appears, an excption occurs: FileNotFoundException: Could not load file or assembly 'Microsoft.Build.Utilities.Core.dll, Version=15.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.
I'm afraid it's because the version of MSBulid according to VS 2019 is 16.8.1. But I can't discover, where it is configured that ver 15.1.0.0. is required. Tried to change relative paths in devenv.exe.config and WcfTestClient.exe.config, with no effect. The project is configured to target framework 4.5.2. If I start debugging in an aspx page (without WcfTestClient), it works fine. If I try it on another machine with both VS 2013 and VS 2019 installed it works also in VS 2019 there.
The project is set with
<Project ToolsVersion="12.0" DefaultTargets="Build"
xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
The required version 15.1.0.0 refers to VS 2017 which I have never installed on my machine.
I tried to change the version and path to the file in all possible configs found under IDE directory of VS, no success.
Then I tried to install vs_buildtools for VS 2017, didn't help (but it is actualy version 15.9).
Finally I've installed MSBuild 15.1, also v12.0, but the error is still the same.
According to the error message, the version=15.1.0.0 msbuild tool should be missing, and the project is created by it. Below are the different versions of msbuild owned by vs and the location of the msbuild.
You can download different versions of msbuild here:msbuild.
You can find Nuget package manager in the tool options, and then select manage nuget packge for solution. In this interface, you can install Microsoft.Build.Utilities.Core.
Related
I'm trying to develop a simple web app using .Net Core 3.0 on an Ubuntu machine.
I setup the .Net Core SDK and the runtime from this link. I setup VS Code and then I create a project using the following commands dotnet new webapp -o RazorPagesMovie code -r RazorPagesMovie
I built the project and it is working. But in VS Code, it shows the following error:
The type or namespace name 'System' could not be found (are you missing a using directive or an assembly reference?)
screenshot of vs code
Regarding your problem, there are multiple open issues on omnisharp-vscode (e.g. 3289, 3290) GitHub repository. A few workarounds are available as follows:
For Windows: install Visual Studio 2019 Community Edition, or MsBuild Tools 2019
For Linux/MacOS: install Mono 6.0.0 or newer
Or uninstall the previous versions of .NET Core. If you don't like these workarounds, the best solution to fix the issue is that installing the new (beta) OmniSharp build for the time being.
You can install this build by adding the following line into your VS Code settings.json:
"omnisharp.path": "1.34.4-beta.7"
Once you save the settings, the new build of omnisharp-vscode with fix will be installed. After the installation, restart IDE if required. I can confirm that the fix works for Windows.
I often get a similar message on .net core 2.x and I find that you have to add the reference to netstandard into the project file to fix as below:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
..
</PropertyGroup>
<ItemGroup>
..
</ItemGroup>
<ItemGroup> <Reference Include="netstandard" /> </ItemGroup>
</Project>
On Mac I tried removing old dot net runtimes and sdks, using the preview version of omnisharp and verifying mono version above 6.0.0
I also deleted project bin and obj dirs, recompiled, deleted nuget cache dirs and restored.
Then I ran across this in related post:
ACK! Upgrading to Mono 6.4 solves problem under Linux!
(Under Mono 6.0 problem occurs as I have had this version before)
Not 6.0 necessarily....
I am installing a C# windows service that uses Geode onto a UAT Windows 2012 server. The referenced dll (like log4net, newtonsoft.json and QuickFix) are working except for Pivotal.Gemfire.dll
When I start the service I get System.IO.FileNotFoundException: Could not load file or assembly 'Pivotal.Gemfire.dll' or one of its dependencies. The specified module could not be found. File name: 'Pivotal.Gemfire.dll'
Now Gacutil doesn't come with Win Server 2012. I've tried installing Windows SDK and .Net SDK and not found a Gacutil executable. So I've tried to get in the dll into the GAC using powershell like this:
[System.Reflection.Assembly]::Load("System.EnterpriseServices, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a")
$publish = New-Object System.EnterpriseServices.Internal.Publish
$publish.GacInstall("D:\Pivotal.Gemfire.dll")
I've tried regsvr32 Pivotal.Gemfire.dll in various flavours
I've tried compiling and running the GacInstall executable at https://github.com/apache/geode-native/tree/develop/executables/GacInstall. It says Installation completed successfully. but when I try to run the service, or try powershell:
([system.reflection.assembly]::loadfile("D:\Pivotal.Gemfire.dll")).FullName
I get the same error.
I've tried a private assembly using runtime assembly binding
<runtime>
<assemblyBinding
xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="Apache.Geode" publicKeyToken="null" culture="neutral" />
<codeBase version="9.1.1-build.2" href="file://Pivotal.Gemfire.dll"/>
</dependentAssembly>
</assemblyBinding>
</runtime>
and various flavours of name Pivotal.Gemfire, Apache.Geode.Client according to Implementing Shared Assembly but always the same error.
Any ideas? Thanks...
UPDATE: Make sure you have x86 and x64 bit C++ packages back to 2013 (for older versions of Geode Net client)
I downloaded the previous version of Geode, 9.0.7, called Gemstone.Gemfire.Cache.dll and got the same error, but that version included a Gemstone.Gemfire.Cache.xml in the same directory. If I took the xml file to my bin directory the error stopped and the service started properly.
So like this the problem is a redundant accompanying xml file to the dll. I fixed the issue by creating a new dummy xml file Pivotal.Gemfire.xml
<?xml version="1.0"?>
<doc>
</doc>
For me the marked answer did not work.
I had to download DependencyWalker which showed me why the Pivotal.Gemfire.dll was not working. One of missing DLLs was from:
Visual C++ Redistributable Packages for Visual Studio 2013
After installing 64x bit, application started to work.
This problem happened again with another install. The answer above using the xml file did not resolve it, it was resolved by downloading version 9.0.7 of the Native Client, Gemstone.Gemfire.Cache.dll and then running
.\gacutil /if C:\Gemstone.Gemfire.Cache.dll
which returned Assembly successfully added to the cache then removing the earlier version of the dll, but retaining the later version Pivotal.Gemfire.dll that I could not get into the GAC because of a strong name issue. This bizarre workaround of getting the earlier version of the dll into the GAC allows the GAC to find - and use - the later version...
This happened to me again with a Geode Native built locally, when it is run on a new Windows 10 install the dependency walker shows missing MSVCP140D.DLL VCRUNTIME140D.DLL and UCRTBASED.DLL as here
The D is related to having built the client in debug mode.
The problem is related to How can I install a Visual Studio C++ redistributable if it is missing? and the answer is either to get a release build of your dll, or to go to Visual Studio Installer, Modify, navigate to Individual components -> compilers, build tools, and runtimes, and check the MSVC v 140 VS 2015 C++ build tools
Yet another time this happened to me and I had to remove references and files to Apache Geode dll built as native client, then reference them all again.
I am getting this error on my CI server:
error MSB4019: The imported project "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\WCF\Microsoft.VisualStudio.ServiceModel.targets" was not found
It seems my WCF service library project references that file, but the VisualStudio folder on Program Files\MSBuild\Microsoft doesn't contain a WCF folder.
I guess I need to install something on the server.
What do I need to install?
Well this ruined my morning, but let's not allow it to ruin anyone else's. I couldn't find this information anywhere else. You need to copy a few files from a development machine with VS Pro 2012.
As aphexddb mentions, you need to copy some targets from C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\WCF to the same location on your CI server.
This then references an assembly called Microsoft.VisualStudio.ServiceModel.Core. You can find this assembly in either the GAC or in the IDE directory at C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE.
Copy this to your CI server and execute gacutil.exe -i Microsoft.VisualStudio.ServiceModel.Core.dll
This was enough to fix it for me.
This isn't the first time I found targets missing from my VS express install in my CI server. I can't help but feel that there is some sort of package I can download from somewhere that fills all this in. Does anyone know of such a thing? If not, perhaps we should create one.
Can still happen on vs2019
error MSB4019: The imported project "C:\Program Files (x86)\Microsoft
Visual
Studio\2019\Professional\MSBuild\Microsoft\VisualStudio\v16.0\WCF\Microsoft.VisualStudio.ServiceModel.targets"
was not found. Confirm that the path in the declaration is
correct, and that the file exists on disk.
WCF is not installed by default as part of 'ASP.NET and web development' workload. To fix this,
On visual studio installer > modify > individual components tab, search for wcf, check, modify - the .targets file gets now installed, msbuild builds ok.
MSBuild auto-detection: using msbuild version '16.3.2.50909' from 'C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\MSBuild\Current\bin'
I ran into this with Visual Studio 2017, for me the resolution was to modify my installation of Visual Studio to include the Windows Communication Foundation components.
Extract this file into folder
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\WCF
The file name is "Microsoft.VisualStudio.ServiceModel.targets"
Now you can solve the problem using the Nuget Package MSBuild.Microsoft.VisualStudio.Web.targets
so the build process does not require any change to the build server.
Install-Package MSBuild.Microsoft.VisualStudio.Web.targets
Details:
remove the element for "ServiceModels.targets" in the .csproj file
remove the target WebApplication from the build command (in yaml)
Ran into this same issue. Did the following to resolve:
Installed the Microsoft Web Platform Installer
Copied Directory "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\WCF" from dev laptop with Visual Studio 2012 to the build server
I've had the same error - my issue was that MS has modified the way MSBuild looks for the versions of VS in the build process template.
Make sure to use the right build process template.
If using TFS2013 and VS2013 use TfvcTemplate.12.xaml
I ran into this same error. In my case, the problem was that my Visual Studio 2008 project didn't get upgraded correctly, probably due to files being marked "read-only" by my source control. To fix it, I loaded the solution in Visual Studio 2015 with everything checked out.
The specific line in the .csproj file changed from
<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\WCF\Microsoft.VisualStudio.ServiceModel.targets" />
To
<Import Project="$(WcfServiceModelTargetPath)\Microsoft.VisualStudio.ServiceModel.targets" />
If you are using VS 2022 build tools, it is no longer in the individual components section. It is on the first tab "Workloads", included in ".NET desktop build tools", you will see it in the list on the right-hand side when you select it.
I have a CruiseControl .NET build server running on Windows Server 2003, and I am trying to build and publish my ClickOnce application using msbuild.
Everything is working fine, except when I enable the bootstrapper of my ClickOnce application. When this happens, I get the following error in the DeploymentGenerateBootstrapper target:
C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets (3939,9):
error MSB3147:
Could not find required file 'setup.bin' in 'E:\Projects\src\TestProject\Engine'.
.NET Framework 3.5 SP1 and 4 and latest Windows SDK for both are installed on the server, but the bootstrapper folder in C:\Program Files\Microsoft SDKs\Windows\versionNo\ does not exist. I tried copying the files from my workstation machine with no luck.
I do not want to install Visual Studio on server and only install the necessary SDKs.
I have also tried copying the bootsrapper folder from my machine
C:\Program Files\Microsoft SDKs\Windows\v6.0A\Bootstrapper
C:\Program Files\Microsoft SDKs\Windows\v7.0A\Bootstrapper
to build server but no luck.
Any ideas?
You will also have to add the associated key and value to the registry to allow MSBuild to find the path to the Bootstrapper folder. I can confirm that this has worked for me using the following regedit.
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\GenericBootstrapper\4.0]
#="0"
"Path"="C:\\Program Files\\Microsoft SDKs\\Windows\\v7.1\\Bootstrapper\\"
Update: According to Emma's TFS Blog it appears the following registry values are checked in order to find the bootstrapper path and if not found looks in your local project folder under the Engine sub folder and then bails with the MSB3147 error if not found there.
HKLM\Software\Microsoft\GenericBootstrapper\<.NET Tools Version>\
HKLM \Software\Microsoft.NetFramework\SDKInstallRoot\Bootstrapper
HKLM \Software\Microsoft\VisualStudio\\InstallDir\Bootstrapper
Reminder: Also remember that there is a 32-bit and a 64-bit registry so be sure to add this value to the same registry that your tools will be accessing.
In the meantime I've also created a feature request to get a more reasonable solution for this issue. Please vote on my feature request to get Microsoft to take a look at it.
BTW, here are a few more links about this issue:
http://social.msdn.microsoft.com/Forums/en-US/msbuild/thread/7672078f-f2bd-4142-b8a9-740c2a8a5ae7
http://social.msdn.microsoft.com/Forums/en/msbuild/thread/6964ba78-5b66-4cd1-bdd1-b31edb76b96a
http://social.msdn.microsoft.com/Forums/en-US/winformssetup/thread/97ac8717-daf7-4554-8dfa-8a63da47a17d
MSBuild: error MSB3147: Could not find required file 'setup.bin'
https://connect.microsoft.com/VisualStudio/feedback/details/361924/remove-bootstrapper-from-microsoft-sdks-directory
http://blogs.msdn.com/b/emmamou/archive/2009/04/08/team-build-for-clickonce-application-with-bootstrapper.aspx?CommentPosted=true#commentmessage
You can also pass the location of the bootstrapper packages to the common Publish target like this:
<PropertyGroup>
<BootstrapperSdkPath>C:\Program Files (x86)\Microsoft SDKs\Windows\v8.0A\Bootstrapper</BootstrapperSdkPath>
</PropertyGroup>
and then
<Target Name="Publish">
<MSBuild Targets="publish" ... Properties="GenerateBootstrapperSdkPath=$(BootstrapperSdkPath); ..."/>
</Target>
I struggled with the same problem on my win7 x64 machine. I have not installed Visual Studio and tried to build and publish a .NET 4.5 WPF solution. I had to add the following keys to the registry
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\GenericBootstrapper\11.0]
"Path"="C:\\Program Files (x86)\\Microsoft SDKs\\Windows\\v8.1A\\Bootstrapper\\"
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\GenericBootstrapper\4.0]
"Path"="C:\\Program Files (x86)\\Microsoft SDKs\\Windows\\v8.1A\\Bootstrapper\\"
You also need to copy the Bootstrapper folders from your dev machine. This blogpost directed me in the right direction http://www.wiktorzychla.com/2013/11/msb3147-could-not-find-required-file-on.html
I had a similar issue to this but in my case I do have Visual Studio installed on the box, and publishing from Visual Studio works fine.
When publishing from the command line with msbuild.exe, the build failed with aforementioned error "MSB3147 Could not find required file 'setup.bin'".
The solution was to explicitly specify what version of Visual Studio to use during build.
<MSBuild
Projects="MyProject.csproj"
Targets="publish"
Properties="Configuration=Release;PublishUrl=C:\AnyFolder;VisualStudioVersion=12.0"/>
I have Visual Studio 2013 on a Win7 x64 machine. My reading of the problem is that MSBuild was looking in the wrong place in the registry. By explicitly telling MS Build to use VS 12.0, it picked the correct registry location entry and consequently the correct path to BootstrapperSdkPath.
I was able to fix this problem by pointing to MSBuild.exe from this location
C:\Program Files (x86)\MSBuild\12.0\Bin\MSBuild.exe
Previously I was pointing to
C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe
Hi I know this answer its soooooo late but just in case
I had to add the Path prop to the task, with the Path where the bootstrapper its located, in my case I used Visual Studio 2015 so the Path is:
**Program Files(x86)\Microsoft Visual Studio 14.0\SDK\Boostrapper**
MSBuild has a Task GenerateBootstrapper in my case
<GenerateBootstrapper>
AplicationFile="$(AppName)"
ApplicationName=..
ApplicationUrl=..
BootstrapperItems=..
Culture=..
ApplicationUrl=..
Path="Program Files(x86)\Microsoft Visual Studio 14.0\SDK\Boostrapper\"
</GenerateBootstrapper>
with this the MSBuild is able to recognize and generate the file
Now i'm stucked with the .net 4 bootstrapper but guess is another story...
I experienced this same error via my TeamCity build server. The cause in my case was that I was running an MSBuild task against my .sln file, with a 'MyProject:publish' target. In this case, the solution+projecth had been updated to target .NET v4.5, but the build server was still configured to use MSBuild Tools 4.0 and .NET v4.0.
Took me a little while to work out the inconsistency between working and non-working branch builds.
I added this line to script. It helped.
call "%VS120COMNTOOLS%vsvars32.bat"
Visual Studio 2013, SDK v8.1A.
Just struggled with this myself - I chose to commit the bootstrapper files to source control. It is possible to override the path to bootstrappers, just provide /p:GenerateBootstrapperSdkPath=.build\Bootstrapper
Then no need to modify registry - and the added benefit that the build is now self-contained.
Only "problem" is that I have to manually copy the Bootstrapper files into source control. In my case (VStudio2015), this meant copying the files from C:\Program Files (x86)\Microsoft Visual Studio 14.0\SDK\Bootstrapper
On a Windows Server 2003 R2 with .NET 4 SDK but without Visual Studio 2010, I have tried building a Visual Studio 2010 solution with
msbuild MySolution.sln /p:RunCodeAnalysis=true
but that fails.
What is required to run code analysis on such an environment?
I get this error message:
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\CodeAnalysis\Microsoft.CodeAnalysis.targets(129,9): error MSB6003:
The specified task executable "FxCopCmd.exe" could not be run.
Could not load file or assembly
'Microsoft.VisualStudio.CodeAnalysis.Sdk, Version=10.0.0.0, Culture=neutral, PublicKeyToken= b03f5f7f11d50a3a'
or one of its dependencies.
The system cannot find the file specified.
I have installed FxCop from the SDK and without luck pointed the variable FxCopDir to the installed location of FxCopCmd.exe, and also setting this registry entry to that location:
HKEY_LOCAL_MACHINE\Software\Microsoft\VisualStudio\10.0\Setup\EDev#FxCopDir
I had the same problem on my MSBuild server and fixed it by:
Installing Windows SDK 7.1
Setting up the registry keys FxCopDir and StanDir in HKEY_LOCAL_MACHINE\Software\Microsoft\VisualStudio\10.0\Setup\EDev (in Win32).
I then copied over from the dev PC, to the FxCop folder on the build server, the following:
The folder Rule Sets (default installation target is here: C:\Program Files (x86)\Microsoft Visual Studio 14.0\Team Tools\Static Analysis Tools\FxCop)
Microsoft.VisualStudio.CodeAnalysis.Sdk.dll
Microsoft.VisualStudio.CodeAnalysis.Phoenix.dll
phx.dll
Do a search for them on your dev PC with Visual Studio installed to locate them.
Then use the .NET 4.0 version of gacutil.exe to install Microsoft.VisualStudio.CodeAnalysis.Sdk.dll to the GAC.
You should then be able to run code analysis as part of an MSBuild build and have it work properly.
An alternative to FxCop would be to use the tool NDepend that lets write Code Rules over C# LINQ Queries (namely CQLinq). Disclaimer: I am one of the developers of the tool
More than 200 code rules are proposed by default. Customizing existing rules or creating your own rules is straightforward thanks to the well-known C# LINQ syntax.
Rules can be verified live in Visual Studio and at Build Process time, in a generated HTML+javascript report.
Another option might be calling FxCop executable as a build task (from msbuildtasks), saving the result as an XML file that can be parsed within most of the CI tools (like Hudson and CC.NET)