May be it's a wrong question, but I need to create a Model/class and access same in azure function. I could not able to find how can I create a class.
Classes may be created inline as it would typically define a class in a regular C# project. Here's an example of a function that defines a class.
You can also define classes in separate files and reference those files using the #load directive as documented here.
Another option is to reference an assembly where your classes are defined, as documented here.
And, a different approach, and yet another option, is to use the newly announced Visual Studio 2017 Tools for Azure Functions
Related
Is there a way of sharing common code across two different Function Apps in Azure?
I understand it is possible to share code between two functions under the same Function App like so:
#load "../Shared/ServiceLogger.csx"
but I would like to share logging code between two different functions, each under it's own Function App. The reason for the functions being under two different Function Apps is that I need one to run on the Consumption plan and the other run on an App Service plan, unless there is another way of doing this?
There is no straightforward way to share code across app boundary in Azure App Sercice, and this holds true both for Function Apps and Web Apps. You will need to deploy the relevant code into each app that needs it.
What I did to get around this before the fix in VS17 Preview (which treats functions as normal cs files and allows project references) is I had a shared class project that had a post build event that would put the dlls into the Azure function projects in a folder. Then reference them with #r "file path to the dll"
One way to reuse code is to use precompiled assemblies / class libraries with your Functions. Donna Malayeri has published a blog post explaining how to achieve this: https://blogs.msdn.microsoft.com/appserviceteam/2017/03/16/publishing-a-net-class-library-as-a-function-app/
Consequently, you could have 2 or more different Functions, deployed to different AppServices or Function instances sharing the same code through a class library. Precompiled assemblies are supported in .NET C# Functions and you can do something similar using WebPack in Node.js based Functions
I have a Win8 app that is purely native (c++) and I've already used a library that is written using managed code AFAIK. No issues there, I created objects and addressed them using C++/CX with ref counted pointers etc.
I need to add a new library, I referenced it as I did previously, but when I declare and object and try to address it I get:
error C3624: 'System::Object': use of this type requires a reference to assembly 'mscorlib'
Using #using <mscorlib.dll> is not a solution obviously, because WinRT does not support #using of a managed assembly.
When I look up the definition of the class I'm using in Object Browser I see that it's inherited from System::Object. The previous library had a class that was inherited from Platform::Object which is valid for C++/CX.
I already contacted the developers of current library I'm trying to use, but it takes a lot of time for them to respond.
Can I work around this issue? What are the possible courses of action?
UPD: Can I ask the developers to rebuild a library for C++/CX?
I do not believe this is going to work in the general case, unless the C# library is a PCL (portable class library). If it leverages anything that is not in the WinRT .NET client profile, it simply will not work.
If it is a PCL, what you can do is write a C# Windows Runtime Component that itself has a reference to this third-party library and wraps the necessary functionality. Then you reference that C# Windows Runtime Component from your C++/Cx application.
Is it possible using EF6 Code First and MVC5 to put all the models, views, and controllers that involve ASP.Identity into its own class library project. So that over multiple web applications you could use that same DLL and already have all the views / controllers / models and be using the same security database for multiple applications?
We have several web applications with separate databases and one security database that handles all of them, and we weren't sure how to keep this model now that we're moving to EF6 Code First and MVC5.
If it is possible could someone point me to a tutorial of something similar or give me a basic outline of steps to go through?
Or if there is a better way to achieve my goal, of having one set of code to handle ASP.NET-Identity security that I can plug that dll into multiple web applications and get the same logic and databases?
Or is this not a good idea in general?
Very open to suggestion and advice. I appreciate it.
Yes it is. We do this with every project that we have. The structure is very simple. Just create a class library project to your solution, add EF to the project, then reference the class library from your main project.
If using Code First Migrations be sure to select the class library project as the default project in the Package Manager console when running migrations or adding migrations.
Here is a pseudo solution structure for your solution
MySolution
- MyWebApp
reference: MyDAL
-MyDAL
reference: EF6
The advantage that I find to this is that you can then reference the "DAL" class library from say a companion console application or windows form application, or a companion website, even in a different solution, and they will use the same code base.
For example:
MySolution
- MyWebApp
reference: MyDAL
- MyDAL
reference: EF6
- MyOtherWebApp
reference: MyDAL
NOTE: Your data context will look for its connection string in the Web.config or App.config in the startup project. NOT the class library. This can be confusing at first... But once you think about how .NET compiles the application together into the final package, it makes sense.
If you're talking about creating one class library for an entire data layer shared between multiple projects, then that's easy enough. You can move all your models, your context, etc. into a class library and run migrations using the class library project. The other projects will just reference that class library and not have migrations of their own.
However, if you're talking about multiple databases and associated data layers, where project Foo has its own models, context and migrations and project Bar has its own models, context and migrations, while the class library has just the IdentityUser and IdentityDbContext, things get a little more complicated. You won't be able to combine any of these contexts. So in your Foo project you'd have to instantiate your context for Foo and your Identity context if you need to work with both. It's not a problem, per se, but it's something to be aware of.
For my Worker role I run a custom task to modify the dll. However, when I use VS to publish the project to Azure the original binary is deployed and not the modified dll. Why is this happening? How to include the modified binary in the package from within VS
This is with sdk+tools v1.6
A possible workaround that I see, is to extract all the code/logic that requires assmebly modification in a separate class library project. Do the custom post-build modification on the class library.
In your worker add reference to that class library. If it also does not work when you add the reference as a project reference, then just copy the resulted modified assembly in a common external references folder for the solution, and add the reference from there (just browse to the final assembly).
I don't know the nature of your modification, but I think that if you cave all your "private" code in a separate class library it will be enough. As the worker implementation will just be calling a "Run()" or similar method of your class library, inside the Run() method of the RoleEntryPoint.
Can I use CustomActionAttribute in classes that inherit from System.Configuration.Install.Installer? I want my class library to support both WiX and Visual Studio setup project.
I don't see any immediate reason why you couldn't do this. One obstacle is that Wix managed CA functions must be declared public static, so you would probably need to refactor most of your logic into functions that could be called by both your Install/Uninstall functions as well as your Wix CAs functions.
If you were to do this I would recommend creating the project from the Votive Managed Custom Action template in Visual Studio and then manually adding a Installer Class to the project. You can then define static functions in the installer class that can be exposed as CAs using the CustomAction attribute.
The reasons for not doing it are:
you can't have methods with same names in your custom actions assembly custom action method calls in WiX
And the DTF methods and VS setup project methods are different in signature.
Also, as I've understood, VS setup project CAs don't use Session object, unlike DTF CAs.