I just updated via nuGet to the latest Azure dll's (Id: Microsoft.WindowsAzure.Caching version 2.0.0.0, runtime version v4). That allowed me to configure a shared cache for my roles.
The problem is when I try to access to the AppFabric Memcache programmatically (another cache, not related to the session).
var servers = new List<DataCacheServerEndpoint>();
servers.Add(new DataCacheServerEndpoint(_hostname, _cacheport));
var conf = new DataCacheFactoryConfiguration();
conf.SecurityProperties = new DataCacheSecurity(secure(_authinfo));
var dataCacheFactory = new DataCacheFactory(conf);
_dataCache = dataCacheFactory.GetDefaultCache();
The code compiles fine but throws a runtime error:
Method not found: 'Void Microsoft.ApplicationServer.Caching.DataCacheSecurity..ctor(System.Security.SecureString)'.
If I take this code and I put the dll's to runtime version 2 works like a champ.
Any idea what should I change in order to make it work?
Edit:
Looks like the old constructor for DataCacheSecurity doesn't allow the secure token any more
http://msdn.microsoft.com/en-us/library/microsoft.applicationserver.caching.datacachesecurity.datacachesecurity(v=ws.10).aspx
Now I just have 2 constructors and looks impossible to specify the auth key
Edit2:
I reached Microsoft and they told me:
“Windows Azure Caching and Windows Azure Shared Caching share the same API, and although the assembly names are the same, the assemblies themselves are different and are in different locations. The Caching NuGet package will remove the Shared Caching assembly references and add the correct Caching assembly references. The Caching assemblies are located in the C:\Program Files\Microsoft SDKs\Windows Azure.NET SDK\2012-10\ref\Caching folder.”
conclusion: it is not possible at the moment.
At this time, the new Azure cache .DLL's (v2) are not compatible with previous versions. You will want to choose one version and make sure that all of your providers comply with it. Obviously, the Dedicated cache needs v2.0 of DataCache DLLs.
Related
ASP.NET Core 2.1
We have a shared dll, that is used in a few projects (via project reference)
We have class in that was named Proofer, and is now named ProofReader.
This was done through mass find and replace.
Nowhere in our source files locally exists any files containing the text Proofer.
VSTS builds the application without issue, then we send it via a release pipeline to Azure. All succeed.
Despite this we attempt to run the web app and get the following:
An unhandled exception occurred while processing the request.
TypeLoadException: Could not load type
'MainShared.Models.Proofer' from assembly 'MainShared,
Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'.
System.Reflection.CustomAttribute._CreateCaObject(RuntimeModule
pModule, IRuntimeMethodInfo pCtor, Byte** ppBlob, Byte* pEndBlob,
Int32* pcNamedArgs)
We are having trouble determining if this is in the build, maybe something not being rebuilt when it should be, or something still cached on Azure that isn't being overwritten.
A few places I can suggest you look into -
If you are using app service web apps in azure , we can use the kudu (web app extension to remove/clean the files) to make sure you have a clean destination.
Check the VSTS Release logs if you have access to , it shows the files which are overwritten and the ones which could not be. Once i had a similar issue and found that the logs were already warning me that a few could not be overwritten.
If you are using VM's for your app deployment if has access to it , remove/backup the files under your site folder.
I had a similar problem after some redesign for a Web App using ASP.NET Core 2.2 (hosted on Azure), that some old not even anymore existing references causing the Load type exceptions to happen and the Web App simply refused to come up. I tried to clean everything up in Visual Studio, even deleted the bin and object directories, but the old reference was still looked for. In Kudu on the Azure portal I saw the *.PrecompiledViews.dll and *.PrecompiledViews.pdb files, which were very old. I simply removed them directly on the Azure server and could then simply start up my app and everything came up again. This fault should be fixed from the source. If I do a complete rebuild, I expect this old garbage to be taken care of during the publishing to the website. This is something that Microsoft should fix and as I can see this happened to others over half a year ago. Thanks Mark Johnson for your very useful hint about those files!
I have an azure function that I want to report what version of the code it is running. In other applications I am able to get this by running something of the nature:
System.Reflection.Assembly.GetExecutingAssembly().GetName().Version
However I don't a) seem to have away of putting that data into the azure function (there is no assembly information button) or b) retrieving that information (the above code snippet always returns 1.0)
Is there a way (other than just putting in a configuration setting or private variable) to pull a standard version value from an Azure function via this mechanism?
I assume you are currently using .csx files from the Azure portal. If you instead switch to using Visual Studio and precompiled assemblies (which is generally recommended) the code you have above should work fine.
Specifically, use the following steps to change the version:
Right click on the Project and choose Properties
Go to 'Package'
Change the Package version
We have a requirement for PDF generation on the fly in our .NET Azure application, and have determined that PDFLib best meets our requirements.
Basic deployment is dll based, and so should be relatively straightforward. While researching the issue, I came across a case-study covering installation of another, similar component (AbcPdf, here), and this led me to wonder if anybody had any similar detailed experience to share regarding getting PDFLib up and running on a cloud service?
Specifically, I'm interested in whether there are any files other than the referenced .dlls which have to be copied with the package, whether I need to install PDFLib to the GAC using a startup command, and if there are any issues getting licensing working in a cloud environment.
We could of course use a VM for this if required, but initially I am looking to use a standard worker role. I am going to ask PDFLib support this question and will share any answer I get here, as I haven't found this topic covered anywhere else on Stackoverflow.
This is what I got back from PDF Lib support, which I think covers everything:
Does the .NET PDFLib require GAC deployment, or can the dlls simply be
copied to the server?
you can simple deploy the pdflib_dotnet dll.
Are there any files other than the referenced dlls which need to be
deployed for PDFLib to work?
no, PDFlib do not have any further dependencies.
How can we authenticate our product license in an environment where we
may not be able to run an installer, and where we may not have access
to the windows registry?
there are multiple ways to to this. The most simple way is to apply the license key in the code. You can also apply a licensefile. Please get in mind, you need for each serve, where PDFlib run in production usage a separate license. For example, when you run the application in a cluster system with 4 nodes (servers), you need 4 licenses.
And, do you have any general guidance on cloud deployments such as this?
we do not have any special comments on this. But I'm sure, you will find a lot of relevant information about the concepts of our PDFlib .NET implementation in the "PDFlib in .NET Howto", which is included in the PDFlib 8 package, and also available on our website:
http://www.pdflib.com/en/developer/technical-documentation/pdflib-in-net-howto/
Let me start with I've not deployed this compment into Azure; however, what follows should be accurate for just about any component you have.
If you can just xcopy deploy this component to a regular server it should just work with a normal deployment package to a Cloud Service; however, if there is an install that is required when you distribute to normal servers (read, NOT your development machine), then you may have some extra steps here. For example, if the install pushes the assembly into the GAC, then you'd have to follow suit.
I'd simply test an xcopy deployment rollout to a regular on premises box that hasn't had an installation of this component before and see if it works. If it does, you're likely just fine to ensure it gets referenced and deployed with your package. If you are concerned that it may need other assemblies to go with it, use something like Reflector, Just Decompile or ILDasm to check out the references the assembly has (careful, using a decompiler on the assembly may be against your EULA).
I know you're asking for actual experience, but I'd say the answer is that this should just work. From http://www.pdflib.com/fileadmin/pdflib/pdf/support/PDFlib-in-.NET-HowTo.pdf:
A process called xcopy deployment is also supported. You can simply
copy the PDFlib assembly (pdflib_dotnet.dll) to the server using the
xcopy command or FTP transfer
I downloaded and PDFLib x64 version and a give a quick try with Windows Azure Web Role. The Library contains only one DLL as PDFlib_dotnet.dll which you can add as reference and set its property "Copy Local As True". After that you can just reference it in your code and use it based on documentation.
Based on my quick test, you really need to modify the code to use Windows Azure Local Storage to create your PDF files and the sync to Windows Azure Blob storage to persist it properly. There may be way to create the PDF directly to Azure Blob storage but I just did not look further.
I created an ASP.NET based webrole with the following code:
PDFlib p;
int font;
p = new PDFlib();
try
{
// This means we must check return values of load_font() etc.
p.set_parameter("errorpolicy", "return");
// Added code to create PDF on Local Storage
LocalResource myStorage = RoleEnvironment.GetLocalResource("myLocalStorage");
string filePath = Path.Combine(myStorage.RootPath, "hello.pdf");
if (p.begin_document(filePath, "") == -1)
{
Console.WriteLine("Error: {0}\n", p.get_errmsg());
return;
}
p.set_info("Creator", "hello.cs");
p.set_info("Author", "Rainer Schaaf");
p.set_info("Title", "Hello, world (.NET/C#)!");
p.begin_page_ext(595, 842, "");
font = p.load_font("Helvetica-Bold", "unicode", "");
if (font == -1)
{
Console.WriteLine("Error: {0}\n", p.get_errmsg());
return;
}
p.setfont(font, 24);
p.set_text_pos(50, 700);
p.show("Hello, world!");
p.continue_text("(says .NET/C#)");
p.end_page_ext("");
p.end_document("");
}
catch (PDFlibException eX)
{
// caught exception thrown by PDFlib
Console.WriteLine("PDFlib exception occurred in hello sample:\n");
Console.WriteLine("[{0}] {1}: {2}\n", eX.get_errnum(),
eX.get_apiname(), eX.get_errmsg());
}
finally
{
if (p != null)
{
p.Dispose();
}
}
}
I have a 3rd party web page screen capture DLL from http://websitesscreenshot.com/ that lets me target a URL and save the page to a image file. I've moved this code into my Azure-based project and when I run it on my local sandboxed dev box and save to the Azure blob, everything is fine. But when I push the bits to my live server on Azure, it's failing.
I think this is because either MSHTML.dll and/or SHDOCVW.dll are missing from my Azure configuration.
How can I get these libraries (plus any dependent binaries) up to Azure?
I found the following advice on an MSFT forum but haven't tried it yet. http://social.msdn.microsoft.com/Forums/en-US/windowsazuredevelopment/thread/0344dcff-6fdd-4479-a3b4-3e89750a92f4/
Hello, I haven't tried mshtml in the cloud. But generally speaking, to
use a native dll in a Web Role, you add the dll to the Web Role
project just like adding a picture (choose add existing items). Then
make sure the Build Action is set to Content. This tells Visual Studio
to copy the dll file to the output package.
Also check dependencies carefully. A lot of problems related to native
code are caused by missing dependencies, such as a particular VC++
runtime dll.
Thought I'd ask here first before I burn a day or two on an unproven solution.
EDIT #1:
it turns out that our problem was not related to MSHTML.dll or SHDOCVW.dll missing from the Azure server. They're there.
The issue is that by default new server instance have the IE security hardening feature enabled, and this was preventing our 3rd party dll from executing script. So we needed to turn off the enhanced IE security configuration settings. This is also a non-trivial exercise.
In the meantime, we just created a server-side version of the feature on our site we need to make screen captures from (e.g. we eliminated JSON-based rendering of UI on the client), and we were able to proceed.
I think the solution mentioned in the MSDN forum thread is correct. You should put them as part of your project files, so that the SDK will package and deploy them to the VM on the cloud.
But if they are COM and need to be registed you'd better call the register command via the Startup feature. Please check http://msdn.microsoft.com/en-us/hh351539
HTH
I have a app fabric service that I want to test. (http://xxx.cloudapp.net:8081/service.svc).
I created a console app and added a service reference to the service and got the following error:
Could not load file or assembly
'Microsoft.ServiceBus,
Version=1.0.0.0, Culture=neutral,
PublicKeyToken=31bf3856ad364e35' or
one of its dependencies. The system
cannot find the file specified.
I added a reference to Microsoft.ServiceBus from C:\Program Files (x86)\Windows Azure platform AppFabric SDK\V1.0\Assemblies\NET4.0
I set all assemblies in my project to Copy Local = True, as suggested here:
http://msdn.microsoft.com/en-us/library/ee706702.aspx
Additional Due diligence:
I opened Microsoft.ServiceBus in red-gate's reflector and confirmed that it is the correct version. Just for kicks, I also added references to each assembly referenced in reflector and set all references to copy local = true.
Any other ideas?
…Peter
Make sure you change the Target Framework (Project properties/Application tab) from '.NET Framework 4 Client Profile' to '.NET Framework 4'.
I found a similar post and that was what helped me.
I believe it has to with the fact that Microsoft.ServiceBus is not supported by the client profile of .NET 4.
When you reference Microsoft.ServiceBus.dll, reference it from the install location, e.g.,
C:\Program Files (x86)\Windows Azure
platform AppFabric
SDK\V1.0\Assemblies\NET4.0\Microsoft.ServiceBus.dll
... not from the GAC, and set Copy Local to true.
You need to do this in whatever you are deploying into Azure; the Microsoft.ServiceBus.dll needs to packaged with your project because it is not available by default in Azure.
If you fire up Fiddler, you see a 500 error when calling the service. This proves that the exception isn't in your calling application.
ServiceBus dll is not installed on Azure boxes
Make sure your reference to the assembly specifies COPY LOCAL
Also make sure you don’t have references to the service bus dll in upper projects which do NOT copy local (this might be your problem if you have verified 1 above)
You can check the CSX tree for your azure build folder to see if the assembly is being copied into the final package. That’s a lot quicker than uploading to azure or starting the dev fabric.
That should solve your problem