I want to use some shared classes on my Azure Functions to not duplicate code.
I have tried to create a empty C# function and create the classes inside the function and then import to the other functions with:
#r "../Shared/Class.cs"
First, put your shared code inside a folder in the root of your Function App directory (e.g. "Shared"). Let's say I put a shared Message.csx class in that folder (e.g. full path D:\home\site\wwwroot\Shared\Message.csx).
To include this into your function use the #load command:
#load "..\Shared\Message.csx"
using System;
using Microsoft.Azure.WebJobs.Host;
public static void Run(Message message, TraceWriter log)
{
log.Info($"C# Queue trigger function processed message: {message.Id}");
}
See the help page here for more information. By default, the files in that directory won't be tracked for changes. If you want to ensure that when files in that directory change your functions will pick up the changes and be recompiled, you can add your "Shared" directory to the watchDirectories list in host.json. E.g.:
{
"watchDirectories": [ "Shared" ]
}
Due to the rate of change within Azure Functions, this is no longer the recommended approach for C# functions( see Azure Functions Tools Roadmap). Refer to the following blog posts for depictions of the most modern and efficient patterns for structure a C# project in visual studio, and get all the advantages of shared DLL's the way you normally do in C#.
https://azure.github.io/AppService/2017/03/16/Publishing-a-.NET-class-library-as-a-Function-App.html
https://github.com/devkimchi/Precompiled-Azure-Functions-Revisited
Let me answer this question in a more human-understandable way taking into account that Azure Functions are new and don't have proper documentation yet.
Let's go step by step.
You need to go to the Azure function "Platform features" section.
Then Navigate to Development tools->Advanced tools:
Next, navigate to Tools->Zip Push Deploy:
Next, create a folder called "Shared" inside root folder as it recommends in Microsoft documentation:
Inside this folder, you can also create additional folders, classes if you want,
for example, if you want to reuse Model classes between Azure functions then create an additional folder called "Models" and put your desired class there.
After the creation of *.csx file you can edit it and put your code there and save:
Then reuse the class inside you Azure function by loading it using #load:
Note:
Yet another way is to use Visual Studio with Microsoft DevOps CI/CD. There it will be much straightforward and easy to do the same.
When working from Visual Studio and looking for a way to share some C# script files between functions within your Function App like this:
#load "..\Shared\MySharedCode.csx"
Please be aware that you should set the 'Copy to Output Directory' property foor the files in your shared folder to 'Copy always'.
Related
We have an azure Webrole which we call as an API from other applications to convert webpages into a rendered byte array which we then attach as a pdf into emails. We do this using ABCpdf.
For our latest project we have to use a second engine from ABC (ABCGecko) in order to render our pages correctly. The ABCGecko engine requires manually copying to the output directory after build occurs, it doesn't happen automatically.
For a normal application this is no issue, I simply copy the required folder (XULRunner_38 for anyone who uses ABC) into the release after building but I can't figure out how to do this for an Azure WebRole and there doesn't seem to be anything much in the way of help from what I can see in google searches.
I'm assuming I either have to build the role and then adjust the package before I deploy, or deploy the role and then copy the folder across after. I can't figure out how to do this though.
If anyone has any ideas or has needed to manually copy files to an Azure Webrole in the past then I would greatly appreciate your help. Also I should mention that we use Visual Studio as our IDE and publish from within there in case that matters to anyone.
Azure web (and worker) roles allow you to define startup tasks, which allows you to call a script (e.g. powershell script, batch file) which can then perform actions such as copying files.
Oh, and if you don't want it to attempt copying in the event a role instance reboots, you'd need to do something like leaving yourself a "breadcrumb" somewhere to signal that you've already done your init work.
What you don't want to ever do is manual copying of content to your role instances. The moment those instances are updated (e.g. new Host OS update) or they're moved to another physical host, you'll lose any of the files you manually copied.
This is all independent of any IDE (aside from general support for the script language you're writing in), since your startup task is going to execute on each web role instance when it starts up.
More details about startup tasks are here.
My application refers to a bunch of xsd files which are used for xml validation. Currently, they are stored in my local directory and I refer it by giving a path to the primary xsd like "C:\TestFolder\TestFile.xsd". This path is stored in the mongo database. I am not sure where do I store the files once I host this application on the Cloud(Azure). And how do I refer that path in mongo? Since there would be many instances of this application running on the cloud, I am not sure what is the best way to solve this problem.
One way could be to store the files in the project and refer them but I don't think that is the best way.
Can someone point me in the right direction?
The xsd files are not changed by the application, they are just used for validation.
Solution 1 (Simple). Make sure you are using the Relative Path and not the Absolute Path when dealing with the files. Also, make sure to import the files into the project and set the “Copy to Output Directory” property to “Copy Always” so that it can be accessed at run time.
Solution 2. You could store your static files as Blob files on Azure and then reference them (there are many tutorials available out there on how to do it). This way, should you accidentally delete your application, those files will not be lost.
Quote from the Azure Web Jobs Documentation:
Persisted files
This is what you can view as your web site's files. They follow a
structure described here. They are rooted in d:\home, which can also
be found using the %HOME% environment variable.
These files are persistent, meaning that you can rely on them staying
there until you do something to change them. Also, they are shared
between all instances of your site (when you scale it up to multiple
instances). Internally, the way this works is that they are stored in
Azure Storage instead of living on the local file system.
Does that imply that by dropping app_offline.htm into the site root folder should pretty much bring down all instances simultaneously?
Yes.
It doesn't bring them down exactly just redirects all traffic to that htm file.
And it's easy to try for example using Visual Studio Online editor:
http://dotnet.dzone.com/articles/first-look-visual-studio
Or the DebugConsole:
http://azure.microsoft.com/blog/2014/03/04/windows-azure-websites-online-tools-you-should-know-about/
Just add the file to wwwroot and browse to your site.
I know that it is possible to pass in parameters via URL to ClickOnce apps launched online. However, most users downloads setup.exe and launch it from their machine. Is there any way that I can re-write setup.exe at download, insert a code (let's say the user's email address), and then have the app launch with knowledge of the code? Assume that we can somehow re-sign setup.exe so that it is legit.
Assume .NET 3.5.
Update The goal here is to pass on either email address and/or referrer information to setup.exe so that even when the user runs the installer from a different machine and a different ip we can figure out who did the referral.
Update 2 Assume .NET 3.5 SP1, does it help? Apparently one can now pass parameters to .application while offline. Is it possible to embed parameters into the setup.exe so that it calls .application?ref=someone right when setup.exe is run?
Well, if your goal is to embed a customer id (email, code, etc) into the exe, the easiest way I can think of is using the IPropertyStorage and IPropertySetStorage interfaces. If you are feeling brave, you could call methods directly on IPropertySetStorage via p/invoke, or you could go the easy route and use Microsoft's prepared COM wrapper, which is called dsofile.dll.
Note that while dsofile is intended for office documents, it does indeed work on any file - including .exe files - you are just stuck with the pre-defined property names. Why not throw your customer id into something like the .Comments property. Just do it in such a way that you can parse it out again.
Here's a sample:
var doc = new OleDocumentPropertiesClass();
doc.Open(pathToFile);
doc.SummaryProperties.Comments = "joe#test.com";
doc.Save();
Of course, you need to first copy it to a temp location, and some time after the user downloads it you'll want to delete it.
You can bundle dsofile.dll with your application and register it as a dependancy and use it in your installer to read the property back out. Or if you can p/invoke the IPropertyStorage without it, then you won't have the dependancy.
The other thing to look into would be using the extended file properties that are read by the Shell32.dll. I just haven't been able to find a clean way to write them easily. If you go this route, please share how you wrote the properties to your .exe.
Have a look whether InPlaceHostingManager class can help you in this case. It won't probably do exactly what you have asked for. But may be able to help...
Any ClickOnce application based on an .exe file can be silently
installed and updated by a custom installer. A custom installer can
implement custom user experience during installation, including custom
dialog boxes for security and maintenance operations. To perform
installation operations, the custom installer uses the
InPlaceHostingManager class.
Walkthrough: Creating a Custom Installer for a ClickOnce Application
EDIT
I am not sure whether you could achieve what you want exactly in the way that you have described in the question. Check whether these threads help you.
Accessing Local and Remote Data in ClickOnce Applications
How to include custom data files in ClickOnce deployment?
How to: Retrieve Query String Information in an Online ClickOnce Application
How would you imagine to "rewrite" setup.exe at download? if instead of opening your application with the provided link (url) users are downloading the file locally directly from the network share, you can't intercept this.
I would try to play with permissions and have the users to execute it from the link provided to them, but unable to connect directly to the share or web address and download it. Not sure this is possible anyway.
You can try embedding that information as a resource into the exe.
Here's a c++ example of updating a resource of an exe. http://msdn.microsoft.com/en-us/library/ms648008(v=vs.85).aspx#_win32_Updating_Resources
You should combine approach by Charith and Josh - essentially, configure your web server so that you can generate a new setup based on URL parameters. Use custom installer to read from the referral information from resource for setup.exe. Check this link for how to manipulate resources for a native application in C# - you have to write to resource file while generating setup and need to read it from your custom installer.
Yet another way of generating custom setup would be to build your executable or helper assemblt from command line embedding the necessary information. And then build the setup from command line tools (see http://msdn.microsoft.com/en-us/library/xc3tc5xx.aspx). It appears to be quite cumbersome and will take long time to generate the custom setup as opposed to modifying the resource of already built setup.
A completely different approach would be to email the unique referral code (registration code) whenever user downloads the application. In the setup (or application), use custom installer to prompt user for this code. If the setup is invoked via URL then the code will be available from there and in such case Custom Installer need not ask for the code. The email that you send when user download the setup should inform user to preseve the code into some text file along with the setup file.
So I've created a simple msi-setup for my application using a setup project and added a couple of custom actions that take care of stuff like extracting files from archives. Now, there are two extra files in my program files -directory which means that the MSI won't remove the directory at the uninstall by itself. My solution to this was to create a custom action that removes the rest of the files.
Now this works just fine and dandy, as long as the default directory is used at installation. But what if the user chooses to change it? I'd assume there has to be a very simple way to read the directory at the custom action, but I'm not quite sure what that is.
As far as I've found out by googling, there are properties such as TARGETDIR related to the MSI-package. However, some sites also say that I should be setting this property by myself, at the installation stage.
All this has left me quite confused. Basically I see two ways to resolve this:
1) Make sure the application does not create files by itself, and the MSI will take care of it. This would mean a bit more work because I'm not responsible for those extra files.
2) Find out the installation directory at the custom action while uninstalling the application, and remove the last bits by myself. This is the quick-and-dirty way as I see it, and would definitely suffice for now. But how to accomplish this?
Also while I'm here I might as well ask this one more related question. As I mentioned earlier, I extract some files at the install. Now, I'd like to get rid of these archives once I've extracted them. The problem is, if I do this, MSI will think my installation is broken and copy them back each time I launch the application. So how to avoid this?
There is no need to use a custom action to remove the files. MSI has built in support for this scenario in two steps:
Use a search to locate the files you want to remove. Here is a tutorial
http://msdn.microsoft.com/en-us/library/aa371564(VS.85).aspx
Then you can schedule a file removal operation to actually delete the files.
http://msdn.microsoft.com/en-us/library/aa371201(VS.85).aspx
Regarding your second question:
Don't add the archives to the File table. Instead create some self extracting archives and use binary custom actions to unpack them.
http://msdn.microsoft.com/en-us/library/aa368085(VS.85).aspx