Noticed that Azure DevOps is no longer showing the menu options in Project Settings for the Extensions.
Does anyone else see this or know why?
I am unable to update settings for the installed extensions.
You can manage the installed extensions in the Organization settings.
Go organization settings--> Extensions under General. See document here for more information.
I have seen the same thing, and it only occurred recently. Yes, the org level extension management is still there, and that only allows for managing which extensions are available to use.
The configuration for the extension usage within each project was a separate section in the project settings - this is missing entirely. We have need to modify one of our extension configs and can no longer access it to do so.
I believe this must be an Error of type PEBKAC coming from a recent MS update to DevOps.
Related
I'm using a company-hosted GitLab Community Edition 11.0.2.
There used to be a menu entry 'Issues' under each project.
For some projects there still is, but not for a specific one.
I remember in previous versions it was possible to turn that feature on/off via the project-settings, but I simply can't find that setting anymore.
It should be included in the Core/Free version, though (Issue Boards has a checkmark for all versions, including Core here: https://about.gitlab.com/pricing/self-managed/feature-comparison/)
How can I enable the built-in issue feature for my personal project?
(I don't need anything fancy, just a list with issues and statuses)
It sounds like it has been disabled for the project (or the company admin has just disabled Issue boards by default on the instance).
You can re-enable it if you are a Maintainer/Owner/Admin for the project in:
Project -> Settings -> General -> Permissions
Project settings documentation.
I'm new to Azure Functions and been thrown into a project without a proper introduction and anybody I could ask is out of office. My simple most likely stupid question is; where can I find the actual code?
In the azure portal, the functions are listed as "read-only" and only contains a function.json. The resource is an App Service and it has a couple of functions. There is no link to any git repository in properties.
Read-only Functions would be compiled and published (e.g. through Visual Studio or a CI/CD pipeline.) The Azure Functions Portal engineers are working on a new, improved experience for this but for now, if your Function app has a deployment source configured, you can view it from the Portal in two ways from your Function app:
Platform Features > Deployment Options.
Platform Features > Resource Explorer. In the file tree on the lefthand side, find your Function app's name, and under that, sourcecontrols. Click to expand in the righthand window.
If your Function app doesn't have a deployment source configured (e.g. your team has been publishing code manually) then things get harder. Depending on how your company has set up their source control and what you already have access to, the function.json you see might help: the entryPoint property in a build-generated function.json will give you the full assembly name of that function (e.g. VSSample.HelloSequence.Run). That or the assembly name of the uploaded DLL in the scriptfile property might help you locate the project.
Good luck! Keep posting if you have further questions; we're here to help.
AFAIK, if we create the azure function in the Visual Studio and publish it to Azure(there may be other ways), it will appear in the situation you described like the screenshot.
Actually, the code is existing in the portal, but the code has been compiled, you could access it in the Platform features -> Advanced tools (Kudu) -> Debug console.
If you want to get the .cs file, I think you should ask it for your coworkers, there will not be in azure.
You said that the Azure function is listed as "read-only". Did you check from the Application Settings menu if you can change the Azure function app edit mode to Read/Write?
As far as I know, regarding web-roles, it is possible to have multiple ServiceConfiguration.cscfg files, one for each publish profile (for example, Cloud1, Cloud2, Cloud3, Local and so on).
Though, is it possible to have different diagnostics.wadcfg (wadcfgx) files?
How to instruct Visual Studio to use a specific diagnostics file when deploying to Azure? Is there a specific entry in the publish profile XML file?
Out of the box, it is not possible because there can be only one diagnostics.wadcfg (wadcfgx) file associated with a role in a cloud project a cloud project.
We are using SDK 2.4 in our project and the way we have worked around this problem is by creating separate cloud projects for each environment - Dev, Staging, and Production. Since these are separate cloud projects, we can have different diagnostics configurations.
If you're using SDK 2.5, one thing that works in your favor is the diagnostics is now an extension (instead of plugin). What that allows you to do is change/enable/disable diagnostics on the fly. Though I have not tried it but one thing you could possibly do is enable diagnostics as a part of your deployment process. By default there won't be any diagnostics.wadcfgx file in your project. When you deploy your code via PowerShell, after successful deployment, you can enable this extension. Please see Step 4 here: http://azure.microsoft.com/en-in/documentation/articles/cloud-services-dotnet-diagnostics/#worker-role. (Since I have not tried it myself, I would be very much interested in knowing the outcome. Please do share if this approach worked for you).
I would like to update the Diagnostic configuration file for the azure roles whenever I upgrade my deployment. How can I do this automatically?
From time to time, we do change our diagnostic (using code) - and upgrade the service. But whenever we upgrade the service, it is still using the old diagnostic configuration and we do not see any new logs we have configured using new code.
How can I achieve this so that whenever I upgrade my deployment, it upgrades the diagnostic configuration as well.
I wonder if you have a bug in your diagnostics updating code. If each role ran code in OnStart or Run to configure diagnostics on startup, there would be no reason that your instances wouldn't be properly configured. I tend to think that imperative code that configures diagnostics is inherently a bad idea in the long run, but it should still work. If you share the code, maybe I can spot an issue.
The best** way I have found to update and enforce configuration is to use the diagnostics.wadcfg file and update it. When you upgrade your deployment, it will use those settings if you have not overridden it in code somewhere. Contrary to Microsoft's guidance at that link, it should be the preferred method as opposed to code which must be maintained and is orthogonal to your application's purpose. Said another way - a declarative configuration file that your ops team can maintain over writing code is usually a better idea. To use this, just include it in your deployment as content and delete any existing files in wad-control-container (and remove any code that configured diagnostics). It will just configure itself from that file then when you next upgrade.
** you can also using a 3rd party SaaS monitoring to set and maintain your diagnostics config. I work on one such one, but I am guessing you want to know how to do it yourself. :)
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