I followed this thread to create a virtual directory in Azure Cloud Services: Windows Azure creating virtual directory to local storage.
It works fine but I'm not able to get "localResourcePath" with the path Azure located the files.
Where do I have to set "MyResource"?
Thanks in advance.
"MyResource" is a LocalStorage resource you define in your CSDEF file - http://msdn.microsoft.com/en-us/library/azure/ee758711.aspx.
You would add the following to your CSDEF (changing sizeInMB as appropriate):
<LocalResources>
<LocalStorage name="MyResource" cleanOnRoleRecycle="false" sizeInMB="1000" />
</LocalResources>
Related
i can deploy an app using Azure service extension in visual studio code which also creates web.config file and the app works fine, but when i try to upload the ZIP file using ZIPdeployUI and manually add the web.config the app throws an error "You do not have permission to view this directory or page". The difference is using Visual studio code the files are uploaded straight into /wwwroot folder and with ZipdeployUI it creates another folder that was zipped on local system.
You do not have permission to view this directory or page.
That is basically a hint that Azure encounter an error while running your web app. Since it's in production, it does not show any useful error messages. For testing/debugging purposes you can turn on the Azure detailed messaging, and turn it back off when it's ready for production. To do so, you have to follow these two steps,
Log in to Azure > App Services (left side menu) > Your Web App > App Service logs (search box is at the top if you can't find it), then turn on Detailed Error Messages or turn on all of the logging options, up to you.
Now add the following in your Web Config file,
In your Web Config file add <customErrors mode="Off" /> BEFORE system.web closing tag, </system.web>. Similarly, add <httpErrors errorMode="Detailed"></httpErrors> BEFORE </system.webServer>. Finally, upload the Web Config to Azure and cross your fingers.
If you follow the steps correctly, that will show the error messages in detail which takes you to figure out the issue.
Few Error Cases-Resolutions were:
You do not... this directory... this error comes when you have restricted IP on IIS Config. Check your web.config file and add your IP address in security section like:
<security>
<ipSecurity allowUnlisted="false">
<clear />
<add ipAddress="192.168.250.70" allowed="true" />
</ipSecurity >
</security>
Remove it if you do not want to restrict any IP address.
Check the zip is unpacked in the path Site>wwwroot>, else try restarting your function or web app.
You might need to tweak this depending on how your application structure looks like after the build like site\wwwroot\dist\, but if you have the app name in the folder structure, you might need to: site\wwwroot\dist\<app-name>\
Sometimes azure active directory authentication was created by Function App / Authentication automatically like (MS Graph - User.Read, Azure Service Management -user_impersonation). If yes, removing those will work to access the directory.
I'm new to Azure Storage and I've been having a problem creating and working with queues locally.
So, firstly I wasn't able to make the Azure Storage Emulator run, so I've changed the config to look like this:
<StorageEmulatorConfig>
<services>
<service name="Blob" url="http://localhost:10000/"/>
<service name="Queue" url="http://localhost:10001/"/>
<service name="Table" url="http://localhost:10002/"/>
</services>
(Originally it had a 127.0.0.1 IP instead of localhost). That change made the Storage Emulator run correctly, but I still only get an endless loading icon when trying to ellapse the Queues (and Blob containers and Tables too, by the way).
So far I've tried:
Creating a new azure storage connection with the same connection string, but replacing the default IP with localhost.
2.Changing the number of the ports in the config file
Restarting everything
Reinstalling Azure Storage Explorer and Emulator
Have you guys ever encountered this type of error, or have any idea what could I try to fix it?
Edit: I have also deleted the .IdentityService folder from my machine. No luck.
I am trying to deploy webjob in azure. It is an existing console app that does a file copy using SFTP.
The appsetting in the app.config file is like below :
<add key="IdentityFile" value="C:\Temp\Uploads\UploadTest.ppk"/>
I know I have to set this in AppSettings section of the AppService but I am not sure what is equivalent to "C:\Temp" in Azure.
Could someone please guide me? Thank you
In Azure App Service, you can still rely on %TMP% to find the temp folder. The folder it goes to is D:\local\Temp, so you could change your config to D:\local\Temp\Uploads\UploadTest.ppk.
Note that you can change this by setting an IdentityFile App Setting in the Azure Portal, instead of changing it in the physical app.config file.
I'm using Windows Azure to host my python project and I'm trying to enable the diagnostics without good results.
As I'm using python and not .NET, the only way I can actually configure it is through config files.
Below my config files:
ServiceDefinition.csdef
...
<Imports>
<Import moduleName="Diagnostics" />
</Imports>
...
ServiceConfiguration.Cloud.cscfg
....
<Setting name="Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString" value="DefaultEndpointsProtocol=https;AccountName=<my-account-name>;AccountKey=<my-account-key"/>
....
diagnostics.wadcfg:
<DiagnosticMonitorConfiguration xmlns="http://schemas.microsoft.com/ServiceHosting/2010/10/DiagnosticsConfiguration"
configurationChangePollInterval="PT10M"
overallQuotaInMB="1200">
<DiagnosticInfrastructureLogs bufferQuotaInMB="100"
scheduledTransferLogLevelFilter="Warning"
scheduledTransferPeriod="PT5M" />
<Logs bufferQuotaInMB="200"
scheduledTransferLogLevelFilter="Warning"
scheduledTransferPeriod="PT5M" />
<Directories bufferQuotaInMB="600"
scheduledTransferPeriod="PT5M">
<CrashDumps container="wad-crash-dumps" directoryQuotaInMB="200" />
<FailedRequestLogs container="wad-frq" directoryQuotaInMB="200" />
<IISLogs container="wad-iis" directoryQuotaInMB="200" />
</Directories>
<WindowsEventLog bufferQuotaInMB="200"
scheduledTransferLogLevelFilter="Warning"
scheduledTransferPeriod="PT5M">
<DataSource name="System!*" />
</WindowsEventLog>
</DiagnosticMonitorConfiguration>
In Diagnostics Manager, I can't actually see any data.
Thanks.
May i ask where your diagnostics.wadcfg located? For a regular worker role the diagnostics.wadcfg must be in the root folder and because you don't have worker role module in your project the location of the architecture of your role folder is very important. Be sure to have exact same folder structure in your Python application as a regular worker role and then drop the diagnostics.wadcfg in the role root folder. (add that info back to your question to verify)
Do you see a diagnostics configuration XML is created in your Windows Azure Blob storage which is configured in the *.Diagnostics.ConnectionString. This is a check which suggests that the diagnostics component in the Azure role was able to read the provided configuration and could create the configuration XML at destination blob stroage (same Azure Storage will be use to write log Azure Table storage). Please verify.
Finally your diagnostics.wadcfg need some more work. As this is a non .net worker role you have configured IIS logging (do you really have IIS running in worker role? ) and also have System event log scheduled to transfer "warning only" so if there are no warnings. Finally the log transfer time is set to 5 minutes which is long during test.
What i can suggest as below to test if diagnostics is working or not:
Remove the IIS log if you dont have IIS running the Azure VM
Replace event log DataSource from System!* to Application!* and set filter to Info level
Change the log transfer time to less then a minutes
Run the exact same code in Development Fabric with Diagnostics connection string connected to Actual Azure Storage.
Add custom event log in your machine and see if they are transferred within the time limit to Azure Table storage and specific tables are created
Above should help you to troubleshoot the problem.
I don't understand why when I call :
LocalResource ls = RoleEnvironment.GetLocalResource("mystorage");
ls.RootPath;
The local folder is not created, I don't understant how it works.
For me, it's a local path that is create. So I should have.
C:\Resources\directory\xxx.HelloAzureWeb.mystorage\
But there is not such file.
Edit:
What I am trying to do is to store some xml scene save files. In a Unity application, I need to post (save them) et get (use them) those files.
There is some misunderstanding you have about creating the local storage. When you call below code, it does not create Local Storage for you, instead it returns back to you an instance of Local Storage object which is created during Application setup:
LocalResource ls = RoleEnvironment.GetLocalResource("mystorage");
To define local storage in your application you either directly add the following in CSDEF (below settings will create a local storage name mystorage, size 2GB and if any case VM is rebooted or role restarts, the local storage will not be clean and content still there:
<LocalResources>
<LocalStorage cleanOnRoleRecycle="false" name="mystorage" sizeInMB="2048" />
</LocalResources>
To add local storage you can also choose ->> [ Visual studio > Role Properties > Local Storage > Add Local Storage ] option as well.
When you define Local Storage in your Windows Azure Application, a new folder will be added as below in your drive C: on Azure VM and this is done when you role is being provisioned in the VM during VM start time:
[In Azure VM]
C:\Resources\directory\[Your_deploymentID].[your_webrolename]_[Role_Instance_Count]\
[In Compute Emulator]
// Lunch your application in Compute Emulator and then open "Compute Emulator UI" to see the Local Storage Path in the command window related to your instance:
C:\Users\avkashc\AppData\Local\dftmp\Resources\3503509c-2112-45ea-8d63-377fe9f78491\directory\mystorage\
Once you will add above local storage specific settings in ServiceDefinition.CSDEF, your local storage will be created and then the following code will work:
LocalResource ls = RoleEnvironment.GetLocalResource("mystorage");
ls.Root // returns the correct local storage path
// Now you can use ls to read/write your data.
For me, the files I store to the storage emulator blobs go into C:\Users\[username]\AppData\Local\DevelopmentStorage\LDB\BlockBlobRoot. Unfortunately, they're not very useful. It's just a bunch of GUIDs, but the filesizes look correct.
Here is how you access Local Storage in your ASP.NET Web Role:
Step 1: Created a very simple ASP.NET Web Role Project
Step 2: Included the following in servicedefinition.csdef:
<LocalResources>
<LocalStorage name="mystorage" cleanOnRoleRecycle="false" sizeInMB="2096" />
</LocalResources>
Step 3: Add the following code in any aspx (in this case about.aspx)
<div>
Local Storage file content: <b><asp:Label ID="fileContent" runat="server" /></b>
</div>
Step 4: Add the following code in any aspx.cs (in this case about.aspx.cs):
protected void Page_Load(object sender, EventArgs e)
{
LocalResource myStorage = RoleEnvironment.GetLocalResource("mystorage");
string filePath = Path.Combine(myStorage.RootPath, "Lesson.txt");
File.WriteAllText(filePath, "First Lesson");
fileContent.Text = File.ReadAllText(filePath);
}
That's it.
I have tested this code in compute emulator and on Cloud and it does work.
When using the storage emulator, Local Resource allocation is just a file directory. The root path looks a bit different from what you describe, but you should be able to navigate to that directory on your local machine, which will initially be empty. You should be seeing it under your \users\you\AppData (which is a hidden directory).
Oh, and local resources have nothing to do with Blob storage. In Windows Azure, it's just a locally-attached disk resource with a specific size quota. It's non-durable storage, unlike Blob storage. Perfect for temporary file writes, caching, etc. and faster than Blob Storage since it's a local disk, but for anything that needs to persist, you'll want to consider Blobs.