I have created an Azure Cloud Service (call it A) in Visual Studio 2013, using Azure SDK v2.6. The cloud service has a single role from project B, project B references project C, and project C references project D. Project D includes a content file called D.dll.config. I have verified that when I build, the file D.dll.config exists in D\bin\Debug\, C\bin\Debug\, and B\bin\Debug\. However, when I run A in both the emulator and on Azure, my config file is absent.
On my local machine, this directory is A\csx\Debug\roles\B\approot\. Does anyone know how to get the configuration file to be included with my cloud service? A brief explanation as to why it is not being included to begin with would also be appreciated.
My coworker stumbled across a solution while he was creating a new cloud service. If I add a reference from project B (the one that contains the cloud service role) to project D (the one that contains the config file as content), then D.dll.config is included in the approot directory in my emulator, as well as in Azure.
This solution is still not ideal, as I have to add an explicit reference to all dll's with content. However, it is the best solution that I know of thus far.
Related
I was trying to deploy my web app to a web app service I created in Azure services portal. I was doing it through Visual Studio Code with the help of Azure extensions (idk if that's important to mention or no). I got this error:
"The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters"
Unfortunately, I can not change file names or move the project to a different folder. What can I do to fix this issue? Thanks in advance :)
Please check if the below steps help to fix the issue:
If it is Node JS Web App, delete the folder called node_modules within the project folder. Reload the solution > Rebuild and publish to the Azure. In the Azure Portal > Web App > Console - run the command npm install which adds the dependencies within that project with the folder called node_modules.
If possible, try to move your projects/solutions to the root directory or to the short directory path.
According to this similar issue reported in the GitHub Repo-Azure Web App, you can include a setting in publish profile file like:
<PublishTempFolderName>i2</PublishTempFolderName>
Check that reference when using the above setting, some global settings need to be applied given on the GitHub Repo
(OR) Enable the policy state of Enable NTFS long paths in the Local Group Policy Editor and check once.
I am working on a small Azure project (using Visual Studio 2015). I have created a Azure Cloud service project with only one webjob. Inside the cloud service project, vs2015 created some subfolders like 'csx', 'ecf', 'XXXXXXXXContent', 'Profile', 'rcf'.
I wonder whether I should checkin these subfolders and the files inside. Of course, the 'Release' and 'Debug' folder inside these subfolders won't be checked in.
Folders with lowercases are generated during compilation and publish process.
csx: Packaged files which ready to be published. But as of Azure Tools v1.4, it is no longer generated unless you run in emulator. This blog post describes in detail.
rcf: which stands for Role Content Files. You already has ---WorkerRoleContent and rcf is generated through build configuration. You can think it as a kind of bin folder for contents.
ecf: It is generated folder for diagnostics settings depended on `diagnostics.wadcfgx' file. The file is specific for publish settings, so you should not include it in source control.
Overall, all three folders are automatically generated for publishing and they should not be added to source control.
However, Profile and ----Content folders are required to maintain your publish settings.
I have the following folder structure in my TFS online:
The folder names also match the project names in the solution.
Legend:
green dot: web api 2.0 project
red dot: class library
blue dot: console app added as a webjob to the web project
grey dot: console app only used for testing
Working folders for build definition:
The build definition was created automatically by connecting Azure to TFS online, and I have only changed the folder, so instead of the Team Project root folder, it points to the folder of this branch, containing the solution file and the folders in the first picture.
(This points to the folder which contains the solution files as well as all the subfolders from the first image.
Problem:
When I run a build, it always picks up the ExpiringRateCardsWorker project (even now the Web project has been renamed (both the directory and the project file) to start with an underscore, so it will be first alphabetically.
The deployment is successful, this is what I see in Monaco:
How can I make it pick up the web project?
Edit: Question was closed stating to be the duplicate of this. I have since tried the solution suggested there, but the /site/deployments folder is empty on the FTP, it doesn't contain the deploy.cmd, so my question is still not answered unfortunatelly.
I'm experiencing similar problem with deployment of MVC application to Azure using CD in VSO.
This problem is somehow related to WebJob Publishing mechanism.
For now I wasn't able to deploy my whole solution with WebJob in one go, but when I've deleted all webjob *.json files and Microsoft WebJobs Publish NuGet package from my solution, I've managed to deploy my MVC App normally.
I think I'll have to deploy this parts of the application separately, for now.
I have an azure web role with Azure SDK 2.3.
My web site project website has web.config, which gets copied to bin/debug/website.dll.config properly during build.
But Azure SDK totally fails to include this DLL in the cspkg which causes my role OnStart to fail, since it depends on binding redirects in the web.config to load the correct version of the Azure runtime assemblies. Anyone got any bright idea why cspack isn't including this file and what to do about it?
web.config files are never copied as projectNAme.dll.config!
Only application.config files are copied this way. And yes, for Web Roles nothing beside the regular web.config are automatically copied.
You have to name your configuration file following the name of your main application assembly (i.e. website.dll.config) and then explicitly mark it with Copy Always in the properties panel, section Copy to output folder. Thus the file will be included into the web role package.
In my code (which has worker role) I need to specify a path to a directory (third party library requires it). Locally I've included folder into project and just give full path to it. However after deployment of course I need a new path. How do I confirm that whole folder has been deployed and how do I determine a new path to it?
Edit:
I added folder to the role node in visual studio and accessed it like this: Path.Combine(Environment.GetEnvironmentVariable("RoleRoot"), "my_folder");
Will this directory be used for reading and writing? If yes, you should use a LocalStorage resource. https://azure.microsoft.com/en-us/documentation/articles/cloud-services-configure-local-storage-resources/ shows how to use this.
If the directory is only for reading (ie. you have binaries or config files there), then you can use the %RoleRoot% environment variable to identify the path where your package was deployed to, then just append whatever folder you refernced in your project (ie. %RoleRoot%\Myfiles).
I'd take a slightly different approach. Place the 3rd party package into Windows Azure blob storage, then during role startup, you can download/extract it and place the files into the available Local storage (giving it whatever permissions the app needs). Then leverage that location from your application via the same local storage configuration entry.
This should help you reduce the size of your deployment package as well as give you the ability to update the 3rd party components without completely redeploying your solution. And by leveraging it on startup, you can guarantee that the files will be there in case the role instance gets torn down and rebuilt.