Trying to use AWS Toolkit to publish Lambda functions using VS 2022 and C#. Builds OK, but publish throws this error. Current TragetFramework is set to net6.0. I tried deleting obj and bin folders, but no help. I do have VS 2019 installed on the same machine and not sure if that is interfering in any way. NuGet Manager version is 6.2.0
error NETSDK1005: Assets file doesn't have a target for 'netcoreapp3.1'. Ensure that restore has run and that you have included 'netcoreapp3.1' in the TargetFrameworks for your project
In my case it was just a matter of deleting the publish profile and creating a new one.
Related
after upgrade to .Net Core 2.1.1 I got this error:
C:\Program Files\dotnet\sdk\2.1.301\NuGet.targets(114,5): error : An error
occurred while retrieving package metadata for 'System.IO.4.3.0' from source
'C:\Program Files\dotnet\sdk\NuGetFallbackFolder'.
C:\Program Files\dotnet\sdk\2.1.301\NuGet.targets(114,5): error : '.',
hexadecimal value 0x00, is an invalid character. Line 1, position 1.
not able to solve it using
nuget.exe locals -clear global-packages
nuget.exe locals -clear packages-cache
nuget.exe locals -clear http-cache
or
nuget.exe locals -clear all
thanks for any help
In my case it was simple, I just did the following:
In Visual Studio, click: TOOLS > NUGET PACKAGE MANAGER > PACKAGE MANAGER SETTINGS
Select Option NUGET PACKAGE MANAGER > GENERAL
In General, click on button CLEAR ALL NUGET CACHE(S) await a few seconds
After this , close all windows and go to TOOLS > NUGET PACKAGE MANAGER > PACKAGE MANAGER CONSOLE
type dotnet restore
done =)
There is a simple solution. Delete the file AppData\Roaming\NuGet\NuGet.config and then run the visual studio it can create the new file of NuGet.config
So I had this issue when ever I used to clone a new repo and my IDE tried to restore the nuget packages first, it would refuse to work without nuget cache being cleard. The below steps helped me fix this after some "investigation".
Delete the nuget config file from (C:\Users<UserName>\AppData\Roaming\NuGet)
In my case the issue was with internal nuget URL. There was some issue with VS IDE unable to communicate with the internal nuget store which had changed from http to https.
Close all instances of VS 2019 and try again.
Once the new internal nuget source was replaced with new url, the issue seemed to have been fixed.
I am running VS 2019 v 16.10.4 #Win 10
I've tried pretty much everything:
Deleted /obj and /bin folders
Cleared NuGet cache
Updated Visual Studio to latest version
Restarted PC
Created a new project and verified that builds, however when adding additional NuGet packages and tried to restore them, got the same issue
Tried some other stuff that I don't recall, however it didn't help
What actually resolved this issue for me was to delete the C:\Program Files\dotnet\sdk\NugetFallbackFolder\ and then run dotnet restore in any of my projects that were failing to build (all of them, which were using NuGet) and then subsequent dotnet build worked ok!
It seems like that folder should be safe to delete (Could I remove or move the folder NuGetFallbackFolder?), however I got a few errors after this with package manager, etc, which I worked around by re-creating an empty C:\Program Files\dotnet\sdk\NugetFallbackFolder\ and it all worked fine after that.
Hope this helps somebody in the same situation! :)
I have a solution running on VS 2017 15.7.4 on Windows 7 and works on 6 machines.
On this new machine (same like the others), I am getting the following when I am trying to compile:
The command ""C:\Projects\MySolution\Source\.nuget\NuGet.exe" install "packages.config" -source "" -NonInteractive -RequireConsent -solutionDir "C:\Projects\MySolution\Source\ "" exited with code 1
Could not find file 'C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\packages.config'.
We tried showing detailed build log, but that wasn't helpful
We rebuilt the machine and same error persisted.
This is a corporate machine with local admin right user account. I am suspecting that the local admin rights might not be implemented properly.
Any suggestions?
NuGet with MSBuild Trying to locate the package.config in VS IDE
folder
Please try to give the full path to the packages.config file:
"C:\Projects\MySolution\Source\.nuget\NuGet.exe" install "<YourProjectPath>\packages.config" -source "C:\Projects\MySolution\Source\"
After hours of investigation, it turned out that the project name is the problem.
The project name (and the namespace) are as follow: MyCompany.MyProject.CMD
(CMD is actually real).
This project was compiling for ages on all machines, however, it didn't do on this particular machine.
We deleted the whole folder structure and recreated it and even formatted the machine.
We tried creating a new project from scratch and calling it the same name - Didn't compile
We tried creating a new project from scratch and called it a different name - Worked!
So solution was changing the project name to MyCompany.MyProject.SomethingElse sorted out the problem. I didn't add CMD as part of the project name, but I will never do and I will pass this to my kids as well.
I didn't want to investigate why it didn't work but CMD resembles the name of the Windows console, would that be the reason? I don't care to know.
What is the purpose of the 'runtimes' folder that gets published along with all my project files? I have a VS Online account, and have the build/deploy process configured through there. The 'runtimes' folder is certainly not a folder that exists in source control or my project folder.
'runtimes' folder contents:
example contents:
Thanks,
Drew
Like #Gregory_Ott I was facing a similar issue where my deployment was an FDD deployment and the 'runtimes' folder was still being created. All I did was, mentioned the runtime and set the self-contained property to false.
In the following example I have used dotnet to publish:
dotnet publish -c Release -o ..\publish --runtime win-x64 --self-contained false
The following link should help you with the deployment:
https://learn.microsoft.com/en-us/dotnet/core/deploying/deploy-with-cli
These exist because you are building your application as a self contained application as opposed to one that is dependent upon the framework being installed on the machine executing it. Documentation can be found at https://learn.microsoft.com/en-us/dotnet/articles/core/deploying/ describing the various options that can be used to control this output.
If portable target runtime is selected, runtime folder is created.
FWIW, I was facing this situation with a .NET 5 application. An empty "runtimes" project was there in the output directory. After wasting a few minutes I realized that the folder was a left-over from a previous build. I deleted bin/obj folders completely and published again and the "runtimes" folder is no longer there in the output. I didn't have to change anything in the project file or build options. Hope it saves someone else a few minutes too.
Could this explain the existence of a runtimes folder in an FDD deployment:
A framework-dependent deployment with third-party dependencies is only
as portable as its third-party dependencies. For example, if a
third-party library only supports macOS, the app isn't portable to
Windows systems. This happens if the third-party dependency itself
depends on native code. A good example of this is Kestrel server,
which requires a native dependency on libuv. When an FDD is created
for an application with this kind of third-party dependency, the
published output contains a folder for each Runtime Identifier (RID)
that the native dependency supports (and that exists in its NuGet
package).
Source: https://learn.microsoft.com/en-us/dotnet/core/deploying/deploy-with-vs?tabs=vs156#framework-dependent-deployment
Setting your RuntimeIdentifier might be the solution. In my case, working with an Azure Function, it cut about 500 megs and reduced my archive down to 174 megs. This is important because on Consumption plans you get very limited storage.
<PropertyGroup>
<TargetFramework>net6.0</TargetFramework>
<LangVersion>preview</LangVersion>
<AzureFunctionsVersion>v4</AzureFunctionsVersion>
<OutputType>Exe</OutputType>
<!--
Prevents the runtimes folder from being created in publish, which contained 500 megs of runtime files we don't need.
-->
<RuntimeIdentifier>win-x86</RuntimeIdentifier>
<PublishReadyToRun>true</PublishReadyToRun>
</PropertyGroup>
In the publish profile in Visual Studio, if Target runtime is set to 'Portable' then all possible runtimes are generated. This is the default, so the output can be reduced by a more selective choice if applicable:
Hi I am banging my head for last few days.
Here is the situation ...
1. I have VSO account which maintains the TFS in cloud.
2. Installed a build server/agent on another machine. (Works fine)
3. Tried to build(XAML build) one solution using that server/controller.
4. Got an error saying ...
"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 build server and the agents are from TFS 2015 and the project is a Visual Studio 2015 project using framework 4.6. I was expecting "v14" folder for target files during build. Why it is trying to find things from "v11" folder ? And how do I solve this.
I know I can copy files to "v11" but I don't want to escape the facts. There should be a reason and a proper fix. Any help would be nice.
Several solutions for you to correct this error:
S1: Install MSBuild.Microsoft.VisualStudio.Web.targets from NuGet gallery via running the following command: Install-Package MSBuild.Microsoft.VisualStudio.Web.targets.
Then replace the following line in your .proj file
<Import Project="$(MSBuildBinPath)\Microsoft.WebApplication.targets" />
with
<Import Project="$..\packages\MSBuild.Microsoft.VisualStudio.Web.targets.14.0.0\tools\VSToolsPath\WebApplications" />
S2: Set the /p:VisualStudioVersion=12.0 MSBuild argument in the build definition.
S3: Copy the Microsoft.VisualStudio.Web.targets file to the C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\WebApplications folder on the build agent machine.
S4: Install VS2012 on the TFS build agent machine just like Patrick mentioned above.
And related cases: Microsoft.WebApplication.targets and Microsoft.WebApplication.targets was not found, on the build server. What's your solution?
The WebApplications\Microsoft.WebApplication.targets (11.0) (which comes from VS2012) is referenced in your web application, so the Visual Studio 2012 should be installed on your build server to resolve this issue.
Be note that, to guarantee TFS build runs successful, you should make sure your build agent machine has the some environment as dev machine.
Did you restore a previous collection on TFS 2015 from a previous TFS version? Did your solution or any projects in your solution get created prior to VS2015?
On my development laptop I have only VS2012 RC installed, and I am successfully able to hook into the new MSDeploy .pubxml plumbing (DeployOnBuild and PublishProfile settings) from powershell (via psake) to deploy my web site to our test server.
However, on my build server, I initially had VS2010 SP1 installed, and I've now additionally installed the 2012 RC (I have other builds on this machine that are still .NET 4).
When running the same script with exactly the same parameters, I see different results between my dev machine and the build server. The command I'm running is
exec { msbuild "Website\WebSite.csproj" /m p:DeployOnBuild=True /p:PublishProfile=MyTestProfile }
On the build server, this does not in fact trigger MSDeploy, but simply the packaging bits that zip the site up and makes a deployment package. My machine successfully picks the pubxml file up and does a successful deployment.
Eventually, I believe I've traced the problem to the file Microsoft.Web.Publishing.targets. On my dev machine I have only
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\Web
but the server additionally has
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\Web
and it seems like this file (without knowledge of the .pubxml stuff) is what's being used there.
Has anybody got any idea what I need to twiddle (preferably within my own msbuild files so I don't screw up anything else on the build server for the 4.0 builds) to get msbuild to pick up the v11.0 version of the file and thereby use my .pubxml file?
That is interesting it should be picking up the latest (v11.0), seems like there is a bug here . This is controlled by the MSBuild property VisualStudioVersion.
Here are the rules for how this value is populated at build time.
1. If VisualStudioVersion is defined as an environment variable or a global property (e.g. /p: on the command line) that wins. This is how Dev11 & the Dev11 command prompt are always v11 – they both define VSV as an environment variable
1. Otherwise, if there is a sub-toolset that matches the equivalent solution version (which is currently always file format version – 1), choose that
1. Otherwise, get the default version; 10.0 if Dev10 is installed, Highest-versioned sub-toolset version installed (currently always 11) otherwise
In your case since you are running into an issue you can pass in the property /p:VisualStudioVersion=11.0 to ensure that the correct targets are used.