Followed the steps to create a sample Azure function from: https://learn.microsoft.com/en-us/azure/azure-functions/functions-create-your-first-function-visual-studio.
The function runs fine locally (using F5), but when I try to publish it to Azure I get the following exception:
2>The "GenerateFunctionsExtensionsMetadata" task could not be instantiated from "C:\Users\<username>\.nuget\packages\microsoft.azure.webjobs.script.extensionsmetadatagenerator\1.2.1\build\..\tools\net46\Microsoft.Azure.WebJobs.Script.ExtensionsMetadataGenerator.dll". Could not load file or assembly 'Microsoft.Azure.WebJobs.Script.ExtensionsMetadataGenerator' or one of its dependencies. The system cannot find the file specified.
2>The "GenerateFunctionsExtensionsMetadata" task has been declared or used incorrectly, or failed during construction. Check the spelling of the task name and the assembly name.
The file "Microsoft.Azure.WebJobs.Script.ExtensionsMetadataGenerator.dll" does exist on the specified location.
The project contains the following NuGet packages:
<PackageReference Include="Microsoft.ApplicationInsights.WorkerService" Version="2.16.0" />
<PackageReference Include="Microsoft.Azure.WebJobs.Extensions.Storage" Version="4.0.3" />
<PackageReference Include="Microsoft.Azure.WebJobs.Script.ExtensionsMetadataGenerator" Version="1.2.1" />
<PackageReference Include="Microsoft.NET.Sdk.Functions" Version="3.0.11" />
Visual Studio version: 16.8.5
What can be done to investigate this problem further?
One or all of the below can solve your issue:
Make sure that all the prerequisites are installed in your Visual Studio 2019:
Delete bin and obj folders in your solution and rebuild. Now, deploy your solution.
Create a function app on your Azure portal, and then select the function app in Visual Studio, instead of creating through Visual Studio, for deployment.
Make sure, your configuration in Visual Studio is set to Release.
Related
I am trying to add a nuget package "Azure.ResourceManager" to an existing project.
Here is the .csproj file:-
<Project Sdk="Microsoft.NET.Sdk">
<ItemGroup>
<PackageReference Include="Azure.Identity" Version="1.6.0" />
<PackageReference Include="Azure.ResourceManager" Version="1.0.0" />
<PackageReference Include="Azure.ResourceManager.Resources" Version="1.0.0" />
....
</ItemGroup>
</Project>
I ran the nuget restore command on the solution, and I have checked that the package is installed through the Visual Studio Package Manager Console, using command
PM> Find-Package ResourceManager
Id Versions Descriptio
n
-- -------- ----------
Azure.ResourceManager {1.0.0} Azure m...
Azure.ResourceManager.Communication {1.0.0} Azure m...
Azure.ResourceManager.Deployment... {1.0.111} This pr...
Azure.ResourceManager.Deployment... {1.0.111} This pa...
However, when I try to import this package into a class, the type cannot be resolved.
I wondered if the package and project targeted different versions, so I checked.
Target frameworks supported by package
Target framework supported by project
In summary,
As far as I can tell, both project and package support .Net Core 3.1 as a target framework.
Package is installed into project, but cannot be imported into class
Another thing I noticed is that the type "ResourceManager" is being searched for in the "Microsoft.Azure" namespace instead of "Azure"
Looking for any pointers to resolve the issue.
I learnt that the issue was happening because of naming conflicts within the namespace that I was trying to add the import in. There seems to have been another namespace "Azure." within the one I was adding code to. Adding a glocal prefix helped resolve the issue.
using global::Azure.ResourceManager;
This seems like a bug. I just created a solution with a .NET core 3.1 project inside. I used the Nuget Manager ui and it worked fine. Have you tried installing it that way?
I am writing a multi-platform c# command line application using .NET Core 3.1 that will need to work as a single executable. I am using Visual Studio 2019 (16.5.4). My OS is Windows 10.0.18363.778 and I intentionally did NOT install Powershell 7. I tested this first bit on my Windows and WSL Ubuntu and it worked until I added Powershell SDK 7. After I installed Microsoft.Powershell.SDK 7.0.0 and when Ì set the project file as follows, everything runs nicely and I can validate I am using PS7 and not Windows PS.
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>netcoreapp3.1</TargetFramework>
</PropertyGroup>
However, when I add the runtimeIdentifier in PropertyGroup:
<RuntimeIdentifier>win-x64</RuntimeIdentifier>
Build successfully completes without errors. However when I ran (both debuging or standalone) and application hits Powershell.Invoke, it throws a FileNotFound Exception with message:
"Could not load file or assembly 'Microsoft.Management.Infrastructure, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'. The system cannot find the file specified."
1) What am I missing to get all depdendencies in the executable directory?
2) When I add the following to create the single executable
<PublishSingleFile>true</PublishSingleFile>
<UseAppHost>true</UseAppHost>
<RuntimeIdentifier>win-x64</RuntimeIdentifier>
It does not get created. I get the executable if I use:
"dotnet publish -r win-x64 -c Debug"
but nothing happens when I run it. (This step used to work fine before PS7)
Is there anthing else I need to do to get the single executable running?
I did some research and figured the following:
Answer 1: There is no Runtime identifer specific Microsoft.Management.Infrastructure.dll files in the runtimes directory. Either Powershell SDK does not support all runtime identifers or its a bug. I will take it to github.
Answer 2: Running the single Executable file is misleading. My expected result was creation of a log file which is created in the application directory. I figured that when the single exe is run, it actually unzips ALL the files to the temp directory and runs the application from there (not the single executable) and hence the log file is not created where the single file executabe is.
To resolve your problem, you have to add this reference to your project. It take me 1 day to found this.
<PackageReference Include="NETStandard.Library" Version="1.6.1" />
Summary:
I'm passing /p:ReferencePath to msbuild, when building a Xamarin.Android project. This does work with Visual Studio 2017, but not with Visual Studio 2019.
In detail:
I have two projects:
Xamarin.Forms (with main class library, iOS and Android project underneath)
Class library
The Xamarin.Forms project is referencing the class library via HintPath directly in Debug build. On the build server (Jenkins) things work differently (release build) and the library is build separately. Therefore I use ReferencePath to overwrite the stored HintPath and reference the class library (dll) on the Jenkins server, which was previously build.
The failing build command looks like this
"C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\MSBuild\Current\Bin\MSBuild"
TestJenkins/TestJenkins/TestJenkins.Android/TestJenkins.Android.csproj
/p:Configuration=Release /p:ReferencePath=C:\Jenkins\workspace\TestMSBuild\MPL1.0
/t:PackageForAndroid /t:Build /v:diag
I left out the other parts, because they do work. When reading the output log I noticed the following, when building with Visual Studio 2019:
the ResolveAssemblyReference task doesn't list the passed ReferencePath under SearchPaths= for the Android build, but it is listed for the class library build (the main library for the Xamarin.Forms project and not the separate class library)
one warning MSB3245
multiple error CS0246
On another Jenkins machine there is Visual Studio 2017 installed and the same code, the same scripts does work without an error. So the question is, what's the difference. Lately, I upgraded to .NET Standard. Perhaps I forgot something?
What I've tried:
set up a similar test project, but here it fails with error CS0103
use hard coded link to the dll with BeforeResolveReferences and this does work, but that is only a hack (continous integration should not work that way)
adding ReferencePath in csproj in Android project, but still the same errors
changed Copy local in the Android project
Visual Studio 2019 does build the project on the Jenkins server, if I update the references and use hard-coded links
read the diagnostic log (140k lines)
read the manual, but the use of RerencePath is not really explained
many more ...
Question:
As you can see I'm using the build tools of Visual Studio 2019, but I don't know what has changed to Visual Studio 2017 Build Tools. Am I calling msbuild wrong? Does /p:ReferencePath works different than I expect? Can someone give me a hint to find the cause for this?
Edit (1):
Now I found the following out: The CS0246 error point to lines in my Android project, where a using statement is made: e.g. using MyClassLibrary.Component.Feature;.
The MSB3245 warning seams to occur if the HintPath in the Android project can't be resolved.
Back to the using statement: I have an interface defined my external class library. A class in the Android project implements this. E.g.
Code in external class library:
public interface ITextService
{
string GetText();
}
Code in Android project:
using SomeLibrary; // error CS0246
using Xamarin.Forms;
[assembly: Dependency(typeof(TestJenkins.Droid.TextService))]
namespace TestJenkins.Droid
{
public class TextService : ITextService // error CS0246
{
public string GetText()
{
return SomeLibrary.ServiceClass.NativeKey;
}
}
}
The question still is, why can't the reference from the Android project be resolved?
Edit (2):
For me that must be a bug in msbuild with VS2019 or a behavior change. So I thought I can combine this with this:
<Project DefaultTargets="Build" InitialTargets="ValidateToolsDllExists" ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Target Name="ValidateToolsDllExists">
<Error
Text=" The ToolsDllPath property must be set on the command line."
Condition="'$(ToolsDllPath)' == ''" />
<Error
Text=" The ToolsDllPath property must be set to the full path to tools.dll."
Condition="!Exists('$(ToolsDllPath)')" />
</Target>
<Target Name="BeforeResolveReferences">
<CreateProperty
Value="$(ToolsDllPath);$(AssemblySearchPaths)">
<Output TaskParameter="Value"
PropertyName="AssemblySearchPaths" />
</CreateProperty>
</Target>
<!-- ... -->
</Project>
But passing /p:ToolsDllPath=C:\path\to\my\dll to msbuild still throws the CS0246 error.
I used a v2 azure function (durable function) with custom dll (.net core 2.2) that calls a service and I get the following exception:
Could not load file or assembly 'System.Private.ServiceModel,
Version=4.1.2.4, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'
In the debugging process, I can't step into the method and the exception is thrown without letting me inside it and I don't know exactly what tried to access that library.
Putting manually the package from .nuget in the bin folder didn't work and the strange thing is that if a run the same code with a sample C# function it works.
fixed
Nuget Install or Update System.Private.ServiceModel
Install-Package System.Private.ServiceModel -Version 4.7.0
https://www.nuget.org/packages/System.Private.ServiceModel/
This issue is detailed here: https://github.com/dotnet/wcf/issues/2824
How I solved it was to download the nuget System.Private.ServiceModel
and add the following to my .csproj
<Target Name="CopySPSM" BeforeTargets="Build">
<Copy SourceFiles="$(USERPROFILE)\.nuget\packages\system.private.servicemodel\4.5.3\runtimes\win\lib\netstandard2.0\System.Private.ServiceModel.dll" DestinationFolder="$(OutputPath)\bin" />
</Target>
I got this with a Blazor 3.1 app. Works fine locally, but, when deployed to Azure I get:
System.IO.FileNotFoundException: Could not load file or assembly 'System.Private.ServiceModel
To fix it, in the Publish Profile, in Visual Studio, I changed the Target runtime from win-x86 to portable
There is a big thread about this on github. I added the PostBuild event as in that thread, but I was still struggling in the CI/CD build pipeline. In the end, I also added a cmd line script step in the build pipeline after the "Build Solution" step with the following code:
copy $(Agent.TempDirectory)\WebAppContent\bin\runtimes\win\lib\netstandard2.0\System.Private.ServiceModel.dll $(Agent.TempDirectory)\WebAppContent\bin\System.Private.ServiceModel.dll
This solution does not seem that clean but it worked for me.
Try to check in your cs.proj if System.Private.ServiceModel.dll is implemanted, if it's not the case you can refer to this work around : https://github.com/dotnet/wcf/issues/2824
i am trying to execute our tests via cmdline.
I use VS2012, but i always get this error:
When i run the tests directly in VS2010 on the same machine they run fine.
I can't use VS2010 for cmdline because we have the wrong license ( assembly finding doesn't work ) so i have to use 2012.
All Windows updates are present.
Has somebody had similar issues with MSTest/VS2012 ?
If you want to keep VS 2012 update 2, 3, or 4 installed, you can try the below workaround:
Run the below commands in the command line:
DEL /S %windir%\*Microsoft.VisualStudio.QualityTools.Tips.UnitTest.AssemblyResolver.ni.dll*
DEL /S %windir%\*Microsoft.VisualStudio.QualityTools.ExecutionCommon.ni.dll*
This is a workaround provided by Microsoft guys.
You need run this batch again after you install Visual Studio updates or sometime even Windows Updates.
I followed Yanhua's Microsoft article link and found a workaround that I liked better than deleting random files:
Use vstest.console.exe instead of mstest.exe.
Note, the arguments for vstest.console.exe are different. It wants a space-separated list of test.dll's
"C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\CommonExtensions\Microsoft\TestWindow\vstest.console.exe" "TestProject1.dll"
Here is my msbuild setup that does the same thing:
<PropertyGroup>
<MSTEST>"$(VS110COMNTOOLS)..\IDE\CommonExtensions\Microsoft\TestWindow\vstest.console.exe"</MSTEST>
</PropertyGroup>
...
<Target Name="MyTests" >
<ItemGroup>
<!-- These Items should be evaluated at Target runtime -->
<TestFiles Include="..\Tests\**\bin\$(Configuration)\*.Test.dll" />
</ItemGroup>
<!-- Run Tests -->
<PropertyGroup>
<!--TestSuccessOrNot is the property specify whether the Test is sucess or not -->
<TestSuccessOrNot>1</TestSuccessOrNot>
</PropertyGroup>
<Exec Command="$(MSTEST) #(TestFiles, ' ')" >
<Output TaskParameter="ExitCode" PropertyName="TestSuccessOrNot"/>
</Exec>
<Error Text="Tests Failed" Condition="$(TestSuccessOrNot) == '1'" />
</Target>
I have had the same problem. I just removed update 2 of Visual Studio 2012.
Steps:
Remove update 2 of Visual studio 2012 (via View installed updates)
Restart system
Change installation of Visual Studio 2012 (via Uninstall or change a program->change->Fix)
Restart system