I'm trying to use MonoDevelop in order to work with .NET Core. In a brand new Linux Mint 20.1 machine, I installed MonoDevelop 7.8.4, and opened a project that I'm working on, and the IDE complained imediatelly:
Getting restore information for solution /home/REDACTED/project.sln
ApplicationName='/usr/bin/mono64', CommandLine='"/usr/lib/mono/msbuild/15.0/bin/MSBuild.dll" "/tmp/NuGetScratch/3r24uwj4.84i.nugetinputs.targets" /t:GenerateRestoreGraphFile /nologo /nr:false /v:q /p:RestoreBuildInParallel="False" /p:RestoreUseSkipNonexistentTargets="False"', CurrentDirectory='/home/REDACTED', Native error= Cannot find the specified file
The file /usr/bin/mono64 does not exist. Anyone knows how I can fix this?
UPDATE
When I try tobuild the project, it fails with the followiing error:
Error: NuGet packages need to be restored before building. NuGet MSBuild targets are missing and are needed for building. The NuGet MSBuild targets are generated when the NuGet packages are restored. (My.App)
This seems to be connected with the previous error message.
I have just installed Ubuntu and for anyone interested I found a solution.
In /usr/bin, make a mono64 symlink to mono-sgen. mono is already a symlink to that.
I will investigate the other tools suggested.
i copied a project from one computer to another. If i open the Project i get a error-message "Das angegebene SDK "Microsoft.NET.Sdk.Web" wurde nicht gefunden." Tanslate: "SDK ..Web not found".
I searched in another questions like here. But i don't have a global.json and i don't know, where i must place it.
And i think the problem is another where. on source computer, the solution can be load. only on target computer i can't load.
Edit: I installed the latest Update of Visual Studio 2017 Community
In the VS installer, make sure you selected the workloads for cross-platform and web development so the required components are added to your VS installation.
I had some different Versions of Core installed. But only the oldest one was used. The command dotnet --version shows me the problem. After deinstalling the old version, i can run my app :).
I had already uninstalled some out of date SDK versions. It turns out that left a dotnet.exe with no related sdk folder at C:\Program Files (x86)\dotnet\dotnet.exe. My machine like most is 64bit and newer sdks are installed at C:\Program Files\dotnet. The cmd path was preferring the older version. I renamed the folder C:\Program Files (x86)\dotnet to C:\Program Files (x86)\dotnet.old (I'm not 100% sure something doesn't crop up that needs the files there so just to be safe). Everything then works.
I have Solution A which has a .NET Core 1.1 class library project. In the Package properties I filled all NuGet fields and selected to create the NuGet upon successful build. This project builds just fine and the NUPKG is created. BTW How can I automatically copy the generated NUPKG to a local directory (my own repository)?
Then I have Solution B which is an ASP.NET Core 1.1 web application. In it I browse to my local repository (where I have manually copied the NUPKG built by Solution A) and install my SolutionA.MyPackage into the web application. VS.2017 says it was successful at installing it. I see it listed in the project's NuGet dependencies.
However, when I try to use ANY of the objects defined in that NuGet package I get a red highlight saying it is not found as if there was no NuGet or assembly reference to that DLL but there is!
What is causing this Visual Studio generated Nuget package to be installed and yet act as if it has not even been referenced?
UPDATE - CSPROJ TARGET
As for copying to my local repository, I added this to CSPROJ but it was not working (somebody had suggested it as I put it). I finally figured out why it did not work, the ItemGroup must be inside the Task.
<Target Name="CopyPackage" AfterTargets="GenerateNuspec">
<ItemGroup>
<MyPackageFiles Include="bin\Release\PackageId.*.nupkg" />
</ItemGroup>
<Copy SourceFiles="#(MyPackageFiles)" DestinationFolder="D:\My Repository\MyNugget\Publish" />
</Target>
UPDATE NuGet Inspection
I opened the NUPKG with NuGet Package Explorer and it shows this more or less:
content\
Properties\
launchSettings.json
Views\
Shared\
rest of my stuff here
contentFiles\
any\
netcoreapp1.1\
Properties\
launchSettings.json
Views\
Shared\
rest of my stuff here
lib\
netcoreapp1.1 (.NEtCoreApp, Version=v1.1)
MyPackage.dll
UPDATE 3
Since NuGet seems to have stopped working (used to work well earlier) I opted for using an Assembly Reference rather than a NuGet (for now). In this situation something odd happens, when coding I can reference ALL the objects in the referenced assembly (former NuGet) and therefore no compilation errors on the main project BUT when I then run the web application I get an internal error because it says
FileNotFoundException: Could not load file or assembly
'MyPackage, Version=0.0.3.0, Culture=neutral, PublicKeyToken=null'.
The system cannot find the file specified.
Unknown location
Which is strange because in the Solution Explorer I see the assembly reference and when I click on it (main application) I can navigate to all the objects that I have defined in that assembly. Why it cannot find it anymore?
It is working again (as it was before!). Today I could open the solutions but when I tried to download an extension (Tools | Extensions) I got an error message about an Access Denied or something like that. It has happened before since I installed to VS.2017.
Of all the Visual Studios I have used since 2002 this has been the most unstable! (and I have update 15.2).
When I saw this error happening again I knew how to get rid of it and thought, "hey, maybe that is what is keeping the NuGet package to be installed but not found or the problem with a direct assembly reference".
So I went to my C:\Users\AppData\USER\Local\Microsoft\VisualStudio\15.2* folder and removed it completely.
After that I the ACCESS DENIED issue went away with the side effect that I had to reinstall all extensions again. I attempted again to install my own NuGet, it did so successfully and as expected (was not happening during the long glitch) the objects were found and the web application worked again.
I want to configure bundling to my new project. I have configured my project with TFS online but I cannot add any packages via nuget and always get this error.
The item F:\Project\MOC\packages\WebGrease.1.5.2\lib\WebGrease.dll could not be found in your workspace, or you do not have permission to access it.
The item F:\Project\MOC\packages\WebGrease.1.5.2\tools\install.ps1 could not be found in your workspace, or you do not have permission to access it.
The item F:\Project\MOC\packages\WebGrease.1.5.2\tools\uninstall.ps1 could not be found in your workspace, or you do not have permission to access it.
This maybe a nuget bug with older version. More details ,please refer the thread from GitHub: Install package fails when solution/project is bound to TFS source control
The bug is during uninstalling packages, nuget will delete package
files from TFS, but if user set disableSourceControllntegration to
true, package files are not added to TFS workplace during installing,
so TFS can't find those files during uninstalling,
The fix is to check disableSourceControlIntegration before deleting
package files from TFS.
Source Link: TFS Error "[file]not be found in your
workspace...."
Also suggest you to update your nuget version to latest and try again.
First some background. At the end of 2012 we migrated our vs2008 solution to vs2010 but we still target .NET 3.5. (I know nothing but the latest and greatest here!)
We hadn't had any issues with this setup until a few weeks ago when people started getting these errors:
"foo.csproj" (Rebuild target) (16:5) ->
C:\...\foo.csproj(142,3): error MSB4019: The imported project "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\WebApplications\Microsoft.WebApplication.targets" was not found. Confirm that the path in the declaration is correct, and that the file exists on disk.
The interesting thing is that if you look at the project file it references v10 which makes sense because we don't use Visual Studio 2012.
This error hit several of us at once and even on older code branches that haven't changed in months.
I suspect some update got pushed onto our machines that confused things but I don't know what to do about it.
The short term solution has been to install VS 2012 and not use it but I'm hoping for something a little cleaner than that.
I ran into the same issue with Visual Studio 2013. It turns out that I was using the old version of MSBuild--the one that ships with the .NET Framework--from the command line. Microsoft is now releasing MSBuild as part of Visual Studio itself and also as a separate installer (http://blogs.msdn.com/b/visualstudio/archive/2013/07/24/msbuild-is-now-part-of-visual-studio.aspx).
The solution was to use the new version of MSBuild.exe located in C:\Program Files (x86)\MSBuild\12.0\Bin. Once I did that, all the targets errors disappeared.
EDIT 1
As mentioned in the comments, each new version of MSBuild brings with it a new directory. For Visual Studio 2015, use C:\Program Files (x86)\MSBuild\14.0\Bin.
EDIT 2
As mentioned in the comments, for Visual Studio 2017, use C:\Program Files (x86)\Microsoft Visual Studio\2017\<Edition>\MSBuild\15.0\Bin\MSBuild.exe.
If you have a build server that does not have VS2012 installed, you can fix this by
a) installing the MSBuild.Microsoft.VisualStudio.Web.targets package to your solution, and
b) replacing this line in the .csproj file:
<Import Project="$(VSToolsPath)\WebApplications\Microsoft.WebApplication.targets" Condition="'$(VSToolsPath)' != ''" />
With this line pointing to the nuget package
<Import Project="..\packages\MSBuild.Microsoft.VisualStudio.Web.targets.11.0.2.1\tools\VSToolsPath\WebApplications\Microsoft.WebApplication.targets" Condition="true" />
EDIT
As #joedragons points out the version in the updated line should match the nuget package version, i.e. replace targets.11.0.2.1 with targets.x.x.x.x for the current version.
A simple solution to this problem:
Go to the following path:
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio
You will see the latest version V10.0, v11.0, v12.0 depending on your Visual Studio 2010, 2012 or 2013 install.
Copy WebApplications folder from either of latest version directory and paste to other.
Your issues should be resolved.
I've found that installing the free Visual Studio 2012 Shell (Isolated) installs the WebApplications v11 MSBuild files. Lighter than a full install of Visual Studio 2012 and no licensing concerns.
Wow. We just saw the same thing happen on our build machine. We use VS2010 and target .NET 4.0. Our project files explicitly import the v10.0 version of these targets. With no changes to the code, yesterday the build was fine and today it's failing with a complaint about a missing v11.0 version. The .NET Framework 4.5.1 got installed/updated last night on this build machine as an automatic update. We're going to force v10.0 with the parameter (or env. variable), but this certainly took us by surprise...
UPDATE: What's even more weird, is that it seems to be the case that today's version of msbuild seems to be using the first line of the sln file to determine which VisualStudioVersion to use by default, whereas yesterday's version did not:
Format Version 12.00
We tested manually changing this to 11.00 and the build started working again.
In our case, even though we're targeting and building everything for 2010/4.0, some devs have been getting ready for VS2012 (since MS claimed that the project files are compatible), and this particular solution was last saved (months ago) in VS2012. Before today, that wasn't causing a problem.
I had the same issue. Fixed by going through above listed solutions. The issue is caused because appropriate version of Visual Studio Tools (BuildTools) is not available on the Build server. As rightly pointed above, this can be resolved by installing BuildTools but is not the option in my case.
Here is another alternative - use Nuget
Install-Package MSBuild.Microsoft.VisualStudio.Web.targets -Version 14.0.0.3
Identify the start up project and Install the web.targets based on the version of Visual studio being used.
The following files will be modified which includes the required changes
In packages.config:
<package id="MSBuild.Microsoft.VisualStudio.Web.targets" version="14.0.0.3" targetFramework="net45" />
In .csproj:
<Import Project="..\packages\MSBuild.Microsoft.VisualStudio.Web.targets.14.0.0.3\build\MSBuild.Microsoft.VisualStudio.Web.targets.props" Condition="Exists('..\packages\MSBuild.Microsoft.VisualStudio.Web.targets.14.0.0.3\build\MSBuild.Microsoft.VisualStudio.Web.targets.props')" />
Hope this helps!!! Good Luck,
Cheers,
Hack, but solved it by copying:
c:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\WebApplications*.*
to
c:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\WebApplications*.*
I got this error in the end of November without making any changes to either the configuration of my TeamCity installation or MSBuild installation or the source code. On my build server Visual Studio isn't even installed, and the change from VS2010 to VS2012 was made in the end of August without any problems at the time.
My MSBuild version is 4.0.30319.18408, my build server is a Windows Server 2008 R2 SP1 with TeamCity v6.5.3.
I solved the issued by simply copying the v11-folder from another build server which was unaffected.
My guess is that this could have happened in two ways:
Something was updated which triggered a deletion of the v11-folder. Could it be a Windows Update to .NET or something?
Something was updated which changed my TeamCity/MSBuild configuration from using v10 to v11 and the builds stop working as the v11 never existed.
I've got a update to .NET Framework 4.5.1 on December 3rd, could that be the reason?
Brgds
Jonas
I've recently got stuck with the same problem. And my conclusion is that every version of VS (v10, v11, v12) changes path of build variable, like MSBuildBinPath.
So specifying exact version of VS isn't a hack, because you might not even have appropriate version of files installed. So intead you'd better specify a parameter and use targets that exist on you machine.
In some rare cases you might need to install specific version of VS and Web Deploy package. In my case just version was enough to solve problem.
You can add the VisualStudioVersion property like this:
<ItemGroup>
<ProjectToBuild Include="$(MSBuildProjectDirectory)\..\MySolution.sln">
<Properties>Configuration=$(BuildConfiguration);WarningLevel=0;VisualStudioVersion=12.0</Properties>
</ProjectToBuild>
</ItemGroup>
<MSBuild Projects="#(ProjectToBuild)" Targets="Rebuild"/>
As I was searching how to solve this one, almost everyone recommended either to copy the missing MSBUILD folder or install some SDK of some version.
Luckily, I've found this awesomely helpful post by Donovan Brown :
http://donovanbrown.com/post/So-sick-of-MicrosoftWebApplicationtargets-was-not-found-build-errors!
In a nutshell, the idea is to configure the VisualStudio version your build should use in your Build Definition:
Right Click -> "Edit Build Definition..."
Go to "Procss" -> "3. Advanced"
and set "MSBuild Arguments" with
/p:VisualStudioVersion=12.0