I've found that when trying to create a fakes assembly for a SharePoint project that references certain SharePoint libraries that I get errors similar to:
Failed to load properly Derived method 'RequiresWebPartClientScript' in type 'Microsoft.Office.Server.Search.WebControls.ScriptWebPart' from assembly 'Microsoft.Office.Server.Search, Version=15.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c' cannot reduce access.
This commonly occurs where the SharePoint project references libraries that are not in the GAC such as: Microsoft.SharePoint.ApplicationPages and Microsoft.ApplicationPages.Administration
It seems that this problem is caused by the fakes generator being unable to resolve the reference when attempting to create fakes. The issue can be worked around by adding a reference to the offending library to the project that will contain the fakes assembly.
For example, if I have a project 'My.SharePoint.Stuff' and I want to run tests in a project 'My.SharePoint.Stuff.Tests' then I would generate a fakes assembly for My.SharePoint.Stuff in My.SharePoint.Stuff.Tests.
Where this fails as described above, the solution is to add a reference to the assembly that is described in the error message to the My.SharePoint.Project.Tests project and then recreate the fake.
Related
I am trying to add some external DLLs to the Acumatica Customisation project but upon publishing it results in "System.BadImageFormatException: Format of the executable (.exe) or library (.dll) is invalid."
Error Image:
I already have added multiple DLLs to the Customisation. And was using the method specified here: Acumatica unable to publish the Customization Package to skip over the errors, but in this case it does not seem to be working.
The first step should be identifying which DLL is the culprit. I suggest you create an empty project and put the files in there one by one with the ignore rules. Maybe you missed to add ignore rule for one of the files.
This error happens because Acumatica attempts to parse the DLL as a .Net framework assembly. If you add non .Net assembly such as native x86/x64 compiled libraries you need to add the ignore rule so Acumatica doesn't attempt to parse it.
If the error is coming from a DLL you compiled, make sure it was compiled in Any CPU platform. This prevents any incompatibility related to 32 bit/64 bit mismatch.
Guys I know that the azure functions cli has a dependency with RestSharp.dll and I think that is conflicting with one of my Azure Functions.
I am getting a runtime type exception
System.TypeLoadException: 'Could not load type 'RestSharp.IAuthenticator' from assembly 'RestSharp, Version=105.2.3.0, Culture=neutral, PublicKeyToken=null'.'
Now my azure function is dependent on RestSharp nuget Version 104.4.0.0. There is no reference in my project to Version 105.2.3.0. Here is the interesting thing. In my despair I searched my entire computer for the culprit dll version 105.2.3.0 and I found it at AppData\local\Azure.Functions.Cli\1.0.12
Is that it ? Is the Azure functions runtime trying to link with its RestSharp.dll version instead of the dll version of my project ?
Runtime should technically load version 104.4.0.0. However it is still loading the version referred by the runtime (105.2.3.0). I was able to verify this behavior. Have filed a bug for this https://github.com/Azure/azure-functions-host/issues/2832.
In the meantime is it possible to do one of the following:
Update the code to use 105.2.3.0, I see RestSharp.IAuthenticator type is present. It is under a different namespace. There should be another method exposing the same functionality
If the function app is not being used in prod. You could use the beta runtime. You should not encounter this issue in beta runtime (v2.x)
So I have some Azure Functions I need to publish, which I want to do via a functions project. However, those functions rely on references to class libraries within my solution, and the references do not work within a functions project, is there a way around this?
Edit: After adding the references to the other projects, when "using" the namespaces in which the classes are kept, the compiler throws an error "cannot resolve symbol", it is as if the reference does not exist. The functions project will not build because it cannot find the namespace in which the classes exist
Verify that each project targets the same version of .NET framework. I had the same problem until I noticed that the referenced project targeted 4.7.1, but my Azure function project targeted 4.6.1. Changing the referenced project to match the Azure function project resolved the issue.
There are a couple more steps to consume assemblies if they're not exposed by default in Azure Functions. If it's a custom assembly you have to make sure it's included in the bin folder. Then you have to make sure you're using the #r directive. Are you doing both of those things? Include your code header and settings if so.
This page has the list of assemblies that are visible to Azure Functions, some still requiring the #r directive:
https://learn.microsoft.com/en-us/azure/azure-functions/functions-reference-csharp#referencing-external-assemblies
The following assemblies are automatically added by the Azure Functions hosting environment:
mscorlib
System
System.Core
System.Xml
System.Net.Http
Microsoft.Azure.WebJobs
Microsoft.Azure.WebJobs.Host
Microsoft.Azure.WebJobs.Extensions
System.Web.Http
System.Net.Http.Formatting
The following assemblies may be referenced by simple-name (for
example, #r "AssemblyName"): Newtonsoft.Json
Microsoft.WindowsAzure.Storage Microsoft.ServiceBus
Microsoft.AspNet.WebHooks.Receivers Microsoft.AspNet.WebHooks.Common
Microsoft.Azure.NotificationHubs
So, the issue is that I have a bunch of internal classes in my assembly that are used by the class I want to test. Since accessors have been removed from VS2012, I'm fine with using [InternalsVisibleTo] and that works great... except when I try to shimify my internal classes, they are not visible to the Fakes framework. I should also note that the particular class I am dealing with is a static class with static methods, and I don't really want to refactor everything to use interfaces (and using stubs) because of resistance in the organization to that level of refactoring.
Is there a way to make these internal members usable by the shims context in Visual Studio 2012 without resorting to interfacing (literally) everything?
The following page describes how to make internal types visible to the generated fakes assembly. http://msdn.microsoft.com/en-us/library/hh708916.aspx#bkmk_internal_types
Which says:
The Fakes code generator will generate shim types and stub types for types that are visible to the generated Fakes assembly. To make internal types of a shimmed assembly visible to Fakes and your test assembly, add InternalsVisibleToAttribute attributes to the shimmed assembly code that gives visibility to the generated Fakes assembly and to the test assembly.
So you need an InternalsVisibleToAttribute that grants your test assembly access to the internal types of the target assembly. In other words:
[assembly: InternalsVisibleTo("TargetAssembly.Fakes")]
[assembly: InternalsVisibleTo("TestAssembly")]
When I deploy my web application to an Azure Web Site, I am getting the following error:
Could not load file or assembly 'FSharp.Core, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.
I have encountered this in the past when deploying to an IIS server and fixed it by installing the F# redistributable http://www.microsoft.com/en-us/download/details.aspx?id=13450
Does anyone know what I can do to get this working on an Azure Web Site (not an Azure Web Role)?
Also, I do have Copy Local set to true for the FSharp.Core library from where it is being referenced.
Reposting from comment:
In my experience, in order to use an F# library from a C# project in Azure, it is necessary to reference FSharp.Core directly from the C# project in order for the proper assemblies to be uploaded. With C#-to-C# project references the 'Copy Local' property seems to propagate correctly, whereas with C#-to-F# references it does not.
I assume compiling with the --standalone flag probably works as well, but I haven't tried it personally.