I have a strange issue that hopefully, someone can help me with. I got a new laptop and I'm trying to publish the same ASP.NET MVC 5 project on the new machine with precompiled views. However, when I do a publish with "Precompile during publishing" option checked, it does not create the precompiled views. Now, if I copy the exact command that it ran and run it in the Command Prompt, the precompiled views are created.
Here are the details. Both machines have Windows 10 Anniversary Update (Version 1607) with Visual Studio 2013 Update 5. Publishing the app on the old machine with the same publish profile generates the precompiled views. On the new machine, publishing from the "Publish Web" dialog runs without errors, but no precompiled views are generated. I then copied this exact command to the Command Prompt that VS used to precompile:
C:\windows\Microsoft.NET\Framework\v4.0.30319\aspnet_compiler.exe -v / -p C:\MyApp\obj\Release\AspnetCompileMerge\Source -c C:\MyApp\obj\Release\AspnetCompileMerge\TempBuildDir
When I ran it, it created the precompiled views in the TempBuildDir\bin directory!
The only difference I can think of between the machines is the Windows Updates.
Any ideas? Thanks.
I ran into exactly the same problem.
It could be an issue with compressed folders (the drive is not compressed, but individual folders are). For some reason, the .compiled files are simply not generated.
This still applies to VS2019 and MVC5. (The latest toolchain as of today. Probably a .NET Framework issue, unrelated to VS and MsBuild versions).
This thread helped me find the solution (see the last answer):
https://social.msdn.microsoft.com/Forums/vstudio/en-US/cb6a4239-9765-4021-a7ab-e5ad3d8aef06/missing-compiled-files-when-publishing-an-aspnet-mvc-4-project-to-filesystem-on-tfs-build-server?forum=msbuild
Do you use the x64 verson of Windows?
Also you can try set $(AspnetCompilerPath) manually:
msbuild.exe /p:AspnetCompilerPath="C:\windows\Microsoft.NET\Framework\v4.0.30319\aspnet_compiler.exe"
or add it to your project:
<PropertyGroup>
<AspnetCompilerPath Condition=" '$(AspnetCompilerPath)'=='' " >C:\windows\Microsoft.NET\Framework\v4.0.30319\aspnet_compiler.exe</AspnetCompilerPath>
</PropertyGroup>
I've made this assumption, because the Microsoft.Web.Publishing.AspNetCompileMerge.targets file contains the string:
We can't use the in-place aspnet_compiler because it will output to the aspnet temp folder which is only suiteable to run on the current machine.
Related
Just a few days ago got this error, after updating to Visual Studio Community 2022 v17.2 (from v17.1.6):
Error NETSDK1005
Assets file 'C:.........XXXXXX.Web\obj\project.assets.json' doesn't have a target for 'net6.0'. Ensure that restore has run and that you have included 'net6.0' in the TargetFrameworks for your project. XXXXXX.Web C:\Program Files\dotnet\sdk\6.0.300\Sdks\Microsoft.NET.Sdk\targets\Microsoft.PackageDependencyResolution.targets 267
Uninstalled everything related with VS2022 + Installer
Rebooted
Fresh Git Cloned the project I'm working on (I work on several computers all with Win 10 and all with the latest updates, this is the only VS installation that presents this problem)
Reinstalled VS 2022 v17.2 (with .NET 6.0, the usual install)
The .csproj file has everything in place:
<PropertyGroup>
<TargetFramework>net6.0</TargetFramework>
<RuntimeIdentifiers>win-x86;win-x64</RuntimeIdentifiers>
<IsPackable>false</IsPackable>
<SpaRoot>ClientApp\</SpaRoot>
<DefaultItemExcludes>$(DefaultItemExcludes);(SpaRoot)\**\node_modules\**;</DefaultItemExcludes>
<AspNetCoreHostingModel>OutOfProcess</AspNetCoreHostingModel>
</PropertyGroup>
Always delete the 'bin' and 'obj' folders before build or rebuild....
Cannot get away with the compilation, and always receiving that NETSDK1005 error...
Getting desperate :(
Thanks in advance for any help
P.S. - already checked question 70711153
I found the problem and it indeed had to do with restoring NuGet Packages, in that I have a connection to a corporate NuGet repository, and the call to it was breaking due to wrong credentials.
What was troubling was that the error did not identify the nature of problem with the connection or the username of the credentials getting refused.
On the logged in user popup dialog window, where the several used usernames are presented, there was one username that was required to re-enter its password.
That was all it took.
Visual Studio > Tools > Options > Azure Service Authentication. ReBuild and the NuGet Packages will be restored and build successful.
We had this issue in our Azure DevOps pipeline and it ended up being that the "NuGet Restore" task was using an old version of NuGet. You can see which version the pipeline is using if you check the logs for the "NuGet Restore" task and look for the "Detected NuGet" line.
We:
added in the "NuGet Tool Installer" task before the "NuGet Restore" task
Under the "Version of NuGet.exe to install", list the version you want to use, or the minimum version (e.g. >=6.1.0)
(this step is possibly overkill) Under the "NuGet Restore" Task, check "Disable local cache"
This happens because NuGet writes a file named project.assets.json in the obj\ folder & the .NET SDK uses it to get information about packages to pass into the compiler. In .NET 5, Nuget added a new field called TargetFrameworkAlias, and thus in MSBuild versions < 16.8 or NuGet versions < 5.8, it is possible that you can generate an assets file without the TargetFrameworkAlias as it will read the property and not find it.
You can resolve this issue by ensuring you are on MSBuild version 16.8+ & using NuGet version 5.8+.
In my case I have commented out the TargetAlias line and it published successfully.
Reference: https://developercommunity.visualstudio.com/t/error-netsdk1005-assets-file-projectassetsjson-doe/1248649
For me, I was getting this when updating my projects from .NET Core 3.1 to .NET 6. I had my .NET 6 code in another Git branch and when I switched from the main 3.1 branch to the 6 branch and then tried to build the solution, I would get that message.
After some trial and error, the solution that worked for me was doing the Git checkout and the restore via command line.
Close the solution
From the Developer Powershell (or using regular Powershell or the Visual Studio 2022 Command Prompt), navigate to the local directory that has your repo, and then:
git checkout [branch name]
dotnet restore
Then back in Visual Studio, reopen the solution and build, which would work.
For me, this happened after switching from .net6.0 to .net 7.0 in asp.net core / blazor project. The error occured when trying to publish the project to IIS.
Solution was to switch the "target framework" in the publishing configuration (.pubxml) in the "Publish"-tab.
For me this fix worked:
If you don't have the dotnet cmd line tool, download and install the .NET 6 SDK.
Open a cmd prompt and run the command:
dotnet restore <path to your solution>
(for instance: dotnet restore c:\app\myapp.sln)
nuget restore resolved the same issue
and/or dotnet restore
I had this bug in a solution with several SDK plus non-SDK C# projects.
What fixed my case:
Close the solution.
Separately open the first project of the solution that Visual Studio failed to build.
Build the project. --> "Error not found and build is OK"
Reopen solution. --> "Error disappeared"
I got the same error when publishing Web API to the cloud.
Use Tools ->Command line -> Developer command prompt in Visual Studio 2022, enter AZ login, and after login, restart the visual studio, it is working for me again.
Had the same problem in Azure Devops, using a Windows 2019 build server with VisualStudio 2022
Error:
##[error]C:\Program Files\dotnet\sdk\6.0.301\Sdks\Microsoft.NET.Sdk\targets\Microsoft.PackageDependencyResolution.targets(267,5): Error NETSDK1005: Assets file 'C:\agent\vso_work\4\s<..>.API\obj\project.assets.json' doesn't have a target for 'net6.0'. Ensure that restore has run and that you have included 'net6.0' in the TargetFrameworks for your project.
Resolved by adding a "NuGet Tool Installer" using version >=6.0.0
Before the NuGet restore task
enter image description here
we got this problem when added cache on gitlab, and started to use dotnet restore,
it happend because we missed the "runtime" parameter to the restore command,
- dotnet restore --packages .nuget --runtime win-x64
- dotnet publish --no-restore --runtime win-x64
In my case the problem was I had updated the Nuget package version in one assembly but not in another, so check you have the same nuget package versions across your solution.
For me, it works to set the target framework to another framework like .NET Core 3.1, build the application, set the framework to the original framework and rebuild.
In my case I had inadvertently added a couple of projects to the solution that were in another folder. I received no errors until I changed NET version from NET6.0 to NET6.0-windows on one of the projects. The solution then didn't build, with 100s of errors, but each individual project built OK.
I noticed that "project.assets.json' doesn't have a target" error among all the errors, pointing to the outside folder.
Bringing those projects into the solution folder fixed the error.
I got the same error sometime back. This worked for me: Logout from visual studio and login to visual studio account
I had an error:
Ensure that restore has run and that you have included 'net6.0' in the
TargetFrameworks for your project. You may also need to include
'win10-x64' in your project's RuntimeIdentifiers.
I removed bin and obj folders for this project and rebuilt the project. dotnet clean, dotnet restore didn't work for me.
I had the same problem ("...\obj\project.assets.json' doesn't have a target for 'net6.0'. Ensure that restore...") with clean batch compilation of my sln: msbuild 17.4, nuget 4.7.
I replaced string
nuget.exe restore my.sln
with string
msbuild.exe my.sln /t:Restore
that was before
msbuild.exe my.sln /t:Build
and everything worked.
I got the same error this morning.
This worked for me: right click on solution explorer in visual studio -> 'Restore NuGet Packages'.
Hope this helps.
I'm currently trying to publish my AWS lambda functions using Visual Studio 2019 community (v4.8.03752) and leveraging the AWS Toolkit for Visual Studio (v1.20.1.0). After right clicking my project and selecting 'Publish to AWS Lambda' I receive the following error:
- Zipping publish folder C:\Users\Matt\source\repos\programName\programName\.\bin\Release\netcoreapp3.1\publish to C:\Users\Matt\AppData\Local\Temp\HelloWorld-CodeUri-Or-ImageUri-637489827969959200.zip
- Failed to find the "build-lambda-zip" utility. This program is required to maintain Linux file permissions in the zip archive.
- Error packaging up project in C:\Users\Matt\source\repos\programName\programName\. for CloudFormation resource HelloWorld: Failed to find the "build-lambda-zip" utility. This program is required to maintain Linux file permissions in the zip archive.
I've been able to deploy this MANY times over previous months, up until Friday 2/12 when I started receiving this error (after a reboot). What's even more strange is that if I uninstall the AWS Toolkit for VS, then reinstall it, I'm able to publish successfully 1 time. With my 2nd attempt, I begin to receive this error again.
Steps I've taken to attempt to resolve:
Repair Visual Studio
Uninstall/Reinstall Visual Studio
Uninstall and reinstall amazon.lambda.tools using dotnet tool install -g Amazon.Lambda.Tools
Uninstall AWS Toolkit for VS, Reinstall toolkit. (This works for first deployment, fails when trying to deploy a 2nd time)
UPDATE:
Per some comments below, it looks like this is being caused by McAfee Real-Time Scanning. In checking the logs during a deployment I noticed a "Virus or threat found" record that points directly to the build-lambda-zip.exe file. To permanently avoid this issue moving forward please follow the steps provided by user2174794 in the comments below.
I'm having the same issue. Just started happening today. It was working within the last 2 weeks.
Failed to find the "build-lambda-zip" utility. This program is required to maintain Linux file permissions in the zip archive.
Running Windows 10, Visual Studio 2019
My solution for now is to use the .NET Core CLI
https://docs.aws.amazon.com/toolkit-for-visual-studio/latest/user-guide/lambda-cli-publish.html
Specifically, the
dotnet lambda deploy-function
A recent update must have broke the AWS Toolkit For Visual Studio.
I have the same problem, it was because my antivirus detect the executable build-lambda-zip.exe, then delete it.
I restore the executable from my antivirus, or restore dotnet tools with the command :
dotnet tool update -g Amazon.Lambda.Tools
I also faced the same issue,
This is because the "build-lambda-zip.exe" file is getting removed by the McAfee Antivirus.
For the permanent fix, you need to follow the below steps.
Step 1
Go to McAfee Settings >> Quarantined Items
You will find the "build-lambda-zip.exe" file there. Restore it to the original location.
Now If you will try to publish, the error won't get displayed. But again on the next scan, the file will get removed.
Step 2
We need to Exclude this file from getting Scanned and removed. So for that,
Go to McAfee Settings >> Real-Time Scanning and Add the "build-lambda-zip.exe" file in the Excluded files list.
For the file path of "build-lambda-zip.exe" got to
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\IDE\Extensions\ and search for the file name.
Maybe you should try reinstalling the AWS Tool Kit and before you make deployments please turn off your antivirus protection. I was troubbling the same issue and my antivirus(McAfee) was deleting build-lambda-zip.exe file when I did deployment first time.
I'm curious about the state of the extension installation. Can you go to VS's extension directory in Windows explorer C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\Common7\IDE\Extensions and in the search box search for AWSToolkitPackage.dll.
Ideally it should only show one instance of that file. Assuming it finds a single instance right click on the file and select "Open File Location". Now that you are in the root folder of the AWS extension check the Resources folder and see if it contains the file build-lambda-zip.exe.
I know the question is in a windows system, but under a linux system, in my case the following command was needed:
sudo apt-get -y install zip
I am exploring the new Entity Framework Core (NOT in conjunction with ASP.Net, what I am coding is just a WinForms app) and found some tutorials mentioning a dotnet command line command needed to create "migrations". When I try it, however, it says 'dotnet' is not recognized as an internal or external command, operable program or batch file. I have searched my hard drive for "dotnet.exe", "dotnet.bat" and "dotnet.cmd" but have found nothing. I use Visual Studio 2015 Community Edition. Where do I find this command executable? What am I to add to the %PATH% environment variable for it to work?
dotnet.exe is located in
C:\Program Files\dotnet>
If you are using command prompt and getting message that 'dotnet' is not recognized as an internal or external command, operable program or batch file" then first check the above path. If you found the above path then just copy it and set it as an environment variable of your PC.
Steps:
Open control panel>System and Security>System
Click on Advanced system settings
In advanced section, click in Environment Variables
In System variables, select path and edit
After semicolon, write "C:\Program Files\dotnet"
Click on Ok button till end.
now to check whether its working on not. Just open command propmpt and type
dotnet --version
This will show the dotnet version installed in your PC.
I've just found the answer myself. It seems like the dotnettool does not get installed with Visual Studio. Installing .NET Core tools preview for Visual Studio (direct link to the .NET Core 1.0.1 tools Preview 2: DotNetCore.1.0.1-VS2015Tools.Preview2.0.3.exe) resolved the problem by adding %ProgramFiles%\dotnet\dotnet.exe.
I have faced another problem after this, however: the dotnet tool running but saying No executable found matching command "dotnet-ef" but this is a matter of another question. I will, however, share the solution here once I find it.
UPDATE:
As promised, here are the question and the answer about the thext problem I have faced (the No executable found matching command "dotnet-ef" error).
And here is the solution for the next one (the ... violates the constraint of type 'TContext' error)
For me it is located at C:\Program Files\dotnet
You need to install .NET SDK separately. You can download and install from https://download.microsoft.com/download/1/1/5/115B762D-2B41-4AF3-9A63-92D9680B9409/dotnet-sdk-2.1.4-win-gs-x64.exe
More details : https://www.microsoft.com/net/learn/get-started/windows
Also I did not have to set up path variable. After running above installation dotnet was automatically added in path. Just open a new cmd and run -
C:\Users\anike>dotnet --version
2.1.4
I have the same issue on windows 10 64bit after installing dotnet core SDK 3.1
To resolve it, I defined the environnement variables path for .netcore 3.1 and restarted my machine.
Download and install .NET core from https://dotnet.microsoft.com/download/dotnet-core, open a new prompt once it's installed.
dotnet
You will get the following message if installation is successful. The path where dotnet.exe is will be added to PATH as part of the installation.
Usage: dotnet [options]
Usage: dotnet [path-to-application]
Options:
-h|--help Display help.
--info Display .NET Core information.
--list-sdks Display the installed SDKs.
--list-runtimes Display the installed runtimes.
path-to-application:
The path to an application .dll file to execute.
If you're using .NET Framework 4.x and WinForms, you probably don't want to use the .NET Core tools (i.e. dotnet ef). Instead, install the Microsoft.EntityFrameworkCore.Tools package and use the NuGet Package Manager Console (or PMC) PowerShell cmdlets: Add-Migration, Update-Database, etc.
To future readers
If on Windows check if you have multiple installations of dotnet on Program Files and Program Files (x86) or Program Files(x32). win + R open cmd, type
where.exe dotnet
only Program Files should have dotnet. Restart Visual Studio .
I had the following error in Visual Studio when first installed .net sdk. I finally just closed VS code, reopened VS Code, and it worked fine.
'dotnet' is not recognized as an internal or external command, operable program or batch file
For windows the reason was that it need to run from a Command prompt outside from visual studio.
execute this command in command prompt,
dotnet run
then application run in https://localhost:5001
I've got a problem with Visual Studio console application created in Ubuntu 15.04. When I try to run c# program in Visual Studio in Windows 10 I get an error "visual project does not contail any commands in project.json and cannot be start". How to fix that?
I have only json file but I don't have any sln and csproj.
The easiest solution: create new, empty console app and paste content (.cs) files from linux repo to it. Build and compile.
Remember to resolve conflicts which may occur (libs used in linux environment may be problematic in windows).
For reference, I'm using Visual Studio 2010.
I have a custom build step defined as follows:
if exist "$(TargetDir)"server.dll copy "$(TargetDir)"server.dll "c:\program files (x86)\myapp\server.dll"
This works great on my desktop, which is running 64-bit Windows. However, when I build on my laptop, c:\Program Files (x86)\ doesn't exist because it's running 32-bit Windows. I'd like to put in something that will work between both editions of Windows, since the project files are under version control and it's a real pain to change the paths every time I work on my laptop.
If this were a *nix environment I'd just create a symlink and be done with it. Any ideas?
You can put this in your project file:
<PropertyGroup>
<ProgramFiles32 Condition="Exists('$(PROGRAMFILES) (x86)')">$(PROGRAMFILES) (x86)</ProgramFiles32>
<ProgramFiles32 Condition="$(ProgramFiles32) == ''">$(PROGRAMFILES)</ProgramFiles32>
</PropertyGroup>
And then you can use $(ProgramFiles32) in your post build event.
For more information check this stackoverflow question.