I am facing a strange problem with packaging an assembly for Azure worker role. I am building a sample Azure cloud application having one website and a worker role. I am referencing a third party assembly, myasm.dll in both website and worker role project. The myasm.dll has dependency on two other assemblies. When I build the project all three(myasm.dll and two dependent assemblies) third party assemblies are getting copied to bin directory for both website and worker role projects. So far so good.
When packaging is done for worker role, off the three third party assemblies, only two assemblies are included in the package, the third assembly is not included. Strangely enough, packaging of Website project includes all three assemblies. I created one more worker role to test the behavior but same behavior was seen again.
Is this a known issue or something? Any help is highly appreciated.
I use VS2012 Update 4.
Package will not include any dll which is not explicitly used in your project or referenced. I know this problem occurs when you do not use type explicitly in a your project(old bug raised - with won't fix status)
I guess your best option is to explicitly reference those missing dll's (see here) or try to add dummy usage of types from missing dependencies.
Related
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
I have an existing project using RIAServices with Entity Framework. The project builds correctly and generates the AmsiWeb.g.cs file with all the context classes for my services.
I am converting my designer based entities and ObjectContext with Code First entities and DbContext. I installed the RIAServices.EntityFramework NuGet package to the web application that contains my services. However, now when I build the AmsiWeb.g.cs file only contains the WebContext class. It doesn't contain any generated services.
I have only at this point converted a single EDMX model to Code First and DbContext and made the requisite changes to the services that use that model to inherit from DbDomainService.
I am using EF 5.0... not sure if that matters cause I'm not sure how adding a DLL to the AmsiWeb application project would break code generation.
What would cause this to no longer work and how can I fix it?
Maybe it's a problem within the msbuild task that generates the proxy code (I mean the *.g.cs file). Probably it's looking for the wrong version of a entity framework. Have a look at this blog post http://mcasamento.blogspot.it/2012/10/entity-framework-5-code-first-and-wcf.html in the final part I wrote an assembly redirect statement that did the trick
It turns out that their needs to be a redirect for Entity Framework 5.0 (4.4.0.0 since I was using .Net 4.0) in the web.config. But, since my RIA Services were in a web application project that was not my root project the code wasn't generating.
Once I added the redirect to the web.config of the web application with the RIA services in it, the context code was correctly generated.
I'm developing ASP.NET MVC with extensive usage of Spring.net.
I have lots of services implemented in different assemblies. The purpose of using Spring and abstract interfaces is to decouple the application from the implementation of services. For example, the Data Access Layer is currently implemented by NHibernate, but the solution is designed to allow this to change.
So I have defined lots of Spring objects from foreign assemblies e.g.
<object id="RepositoryFactory" type="Org.Zighinetto.MyApp.NHibernateBasedRepositoryFactory, Org.Zighinetto.MyApp,NHibernate" />
As we all know, this works as soon as Org.Zighinetto.MyApp.NHibernate.dll example assembly either
Is in GAC
Is in bin directory
As of today, in order to allow quick debugging by hitting F5, I have set a dependency from the main project to all projects it depends on. As we all know, Spring is designed to allow us to cut the dependency between projects, but in this case I use dependencies only to tell Visual Studio to compile and deploy the DLL automatically, otherwise I would have to copy the right DLLs every time I want to debug my project.
The question is straightforward: given that I want to compile, at least in Release mode, my DLLs without unneeded dependencies, how can I make sure that Visual Studio, when I hit F5, automatically compile and deploys all of the Spring-required DLLs (which can be hardcoded by me somewhere, e.g. in a post-compile script) into bin directory?
In the Org.Zighinetto.MyApp example above, I want that once Org.Zighinetto.MyApp.dll gets compiled, VS compiles and deploy also Org.Zighinetto.MyApp.NHibernate.dll without having an explicit reference from .MyApp to .NHibernate
The dependency in you project file does not make the resulting assembly in any way dependent on these referenced files. You can safely have the dependencies there during development and compile your project.
The resulting output will still work when you swap out the assemblies that contain the implementation.
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.
This is related to the this question and the answer maybe the same but
I'll ask anyways.
I understand that we can start managed executables from the network from .NET
3.5 SP1 but what about assemblies loaded from inside the executable?
Does the same thing apply?
You have been able to load Assemblies from the network at leasst from .NET 2.0. I have used this on a previous project. The only thing to watch is the size of the assembly and the number and size of the dependancies that it is loading.
If you are using a seperate AppDomain, then you will need to take special consideration of the dependancies.
My understanding is yes, you're trying to load an untrusted module into your local app domain.