We are trying to generate code coverage on performing manual tests for application hosted in Azure app services.
I have a trail account in portal.azure.com with 'user' privilege.
Tried the below options:
A. Use VS tools in Azure console and local
B. Use OpenCover in Azure console
Both the above mentioned options using VS tools and Opencover has been used in the localhost (IIS server) to successfully generate code coverage on runnign manual tests.
A. Steps for code coverage using VS tools in Azure:
1. cd D:\Program Files (x86)\Microsoft Visual Studio 15.0\Team Tools\Performance Tools
2. vsinstr /coverage D:\home\site\wwwroot\bin\abc.dll
3. vsperfcmd /start:coverage /output:D:\home\LogFiles\Testing123.coverage
4. vsperfcmd -shutdown
Issue1: The generated code coverage file has error: Empty results generated: No binaries were instrumented. Make sure the tests ran, required binaries were loaded, had matching symbol files, and were not excluded through custom settings. For more information see https://go.microsoft.com/fwlink/?LinkID=253731
However I'm able to generate code coverage on the same application which has been hosted in my local IIS server. The same 4 steps mentioned above is working. The issue is that the instrumented dll doesn't log the transactions performed on the hosted application.
Reference: https://gurunadhduvvuru.wordpress.com/2014/08/01/generating-functional-testing-code-coverage/
PS: We have tried starting the coverage process before and after publish the application.
B. Steps for code coverage using Open Cover in Azure
1. OpenCover.Console.exe -target:C:\Windows\System32\inetsrv\w3wp.exe -targetargs:"-debug -s 1" -targetdir:C:\inetpub\wwwroot\bin\ -filter:+[] -register:user -output:C:\Users\coverage2.xml
Issue 2: Access denied is displayed when the application is not running.
Issue 3: The generated coverage file is empty and doesn't has the same error mentioned in Issue 1, on executing the opencover command when the application is running.
Reference: https://automationrhapsody.com/code-coverage-manual-automated-tests-opencover-net-applications/
Any help on the reason for the generated coverage file to be empty ? or any reference to suffice my requirement would be much appreciated?
It appears that it is a limitation of Azure WebApp Sandbox, all Azure Web Apps run in a secure environment called a sandbox. Each app runs inside its own sandbox, isolating its execution from other instances on the same machine as well as providing an additional degree of security and privacy which would otherwise not be available.
You cannot install arbitrary software when running on Azure App Service. Generally, you cannot make any machine level changes (e.g. registry changes).
Reference: https://github.com/projectkudu/kudu/wiki/Azure-Web-App-sandbox. If your requirement fits, try this on an Azure VM running IIS, where you have greater control on managing the VM.
Related
I have made a task for Azure Devops Server pipeline.
On the local Azure Dev-Ops server, I can upload extensions from the local machine wrapped in VSIX file and examine the agent on the machine itself. The agent has the deployed DLL's from the extension and I always change specific DLL that has Logger inside and it prints to console on the pipeline itself.
How can I check if my task is compatible with the cloud version?
And off course if it is, how can I debug it?
The only possible way I found to insert my task in VSO is through the Microsoft DevOps marketplace, but I cannot upload the whole extension once per each change in code.
Also, didn't find a way to upload personal tasks to the marketplace. The private version is not helping because I can see it from within the server just like my clients.
Any advice or debug experience on that platform is appreciated.
Please follow this devblogs, it described how you can work and debug extension directly inside your IDE without publishing it to the marketplace.
Since this blog is very detailed, just mention the key steps.
Based on debugging purposes, you need create a special manifest, for sample I specify it as vss-extension-debug.json:
{
...
"id": "dev-extension",
"name": "Dev-Extension",
"baseUri": "https://localhost:44362",
...
}
You can customized the id and name by yourself. The most important and magic is baseUri, this will tell the VSTS server to load the extension from localhost where we can run and debug it in IISExpress from Visual Studio.
Note: Since our server need extension served from a secure source, please ensure enable SSL mode to run IISExpress
A website with webjob not deploying to Azure.
I am having an issue getting a website with an associated webjob console application to deploy using continuous deployment via Visual Studio Online. I am using VS2013 with update 4 and latest Azure SDK.
The website, and the associated webjob, will publish to Azure using direct publish for Visual Studio and works perfectly, so I am confident the publish settings are fine.
The solution will build and work locally fine.
The solution, once checked in, will build and (seemingly) deploy fine in VSO (using CI) and Azure notes the build was successful and shows it as 'Active deployment'.
However, the website and associated webjob will not be updated.
When I have browsed the deployed files after the VSO build and deploy on Azure, all that is happening, is the binaries of the console app are being copied into the bin/ folder of the website.
None of the website files are being updated. It is almost as if it is deploying the wrong project!
If I remove the Webjob and just deploy the website, it will build and deploy fine through VSO - the website will update.
It is adding the webjob that causes some issue with the deployment via VSO.
I am confident all steps are correct to add the webjob to the WebApp, with the correct webjobs-list.json being added to the webapp and webjob-publish-settings.json to the Console app - as I said, publishing the website (with the webjob) direct to Azure works perfectly, and both the site and webjob get updated.
I have searched post after post and tried all manner of things, but none have worked.
Given the fact this published fine direct from VS, and also that the build is completing, it would suggest that something is wrong with the VSO Build Defintion.
My first guess would be to change it from building the solution to instead building the web project only, but this does not seem to work.
I have also tried every Output location setting (both for the solution build and the web project build) - the only one that works and the build completes is the solution (.sln) build with 'SingleFolder' set.
I have been battling this for a couple of days now an I'm a bit stumped!
This also happens if you have a static website being deployed using a Visual Studio solution via VSO with an automated build - unless the Visual Studio project / solution containing the website is changed then the actual site contents will not be redeployed.
I think your hunch that it's deploying the wrong project is correct. If you have multiple "deployable" projects in your solution (and the console app is considered deployable, as this is one way you can host/deploy a webjob), you need to tell Kudu which one to deploy.
You can control it adding a new setting under "app settings" on the "configure" tab for the webapp.
The setting you want is Project and it's a relative path from the solution root to the .csproj file of your web project.
Alternatively, you can specify the setting in a custom .deployment file.
Relevant Kudu documentation here
From the documentation:
You can specify the full path to the project file. Note that this is not a path to the solution file (.sln), but to the project file (.csproj/.vbproj). The reason for this is that Kudu only builds the minimal dependency tree for this project, and avoids building unrelated projects in the solution that are not needed by the web project.
Here is an example:
[config]
project = WebProject/WebProject.csproj
I have also tried every Output location setting (both for the solution build and the web project build) - the only one that works and the build completes is the solution (.sln) build with 'SingleFolder' set
That's the root case of problem.
You can't have SingleFolder as it sets the OutDir which mess up with web job packaging.
I had to introduce a wpp.targets files in each of my web app project to create the publish package to a particular path (using PackageLocation)
So, let each project have that and set the setting to AsConfigured (or Per Project) instead of SingleFolder.
See this
I'm using Visual Studio 2012 and the publishing feature. I have created a publishing profile that deploys my application to a development server, and it works great when executed from vs2012 on my machine. Here is my problem; on the development server I also have TeamCity installed and I would like to trigger the publishing after a build have completed. So I created a simple build step that looks like this:
Build file path: .\src\Solution.sln
Targets: Rebuild
Command line parameters: /p:DeployOnBuild=true;PublishProfile=Ci
When this step is executing I get the following error:
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\Web\Microsoft.Web.Publishing.targets(4377, 5): error ERROR_USER_NOT_ADMIN: Web deployment task failed.
(Connected to 'dev.domain.com' using the Web Deployment Agent Service, but could not authorize. Make sure you are an administrator on 'dev.domain.com'.
The Ci profile contains a username and password that works when I run the publishing from Visual Studio on my machine. I have also tried passing in username and password as parameters in the build step, but I get the same result. Do I need to run the TeamCity services under admin accounts to get this working? All suggestions are appreciated.
I have just blogged about this at http://sedodream.com/2013/01/06/CommandLineWebProjectPublishing.aspx.
You are pretty close, hopefully I can close the gap.
You are correct that username and password are specified in the VS publish dialog, but we do not save the password in the .pubxml file. It is currently being saved in the .pubxml.user file, and that file is not used at all for command line scenarios. Because of that you will need to pass in the property. So in your case it should be
msbuild .\src\solution.sln /p:DeployOnBuild=true /p:PublishProfile=ci /p:Password=<insert-password>
If your web server does not have trusted certs you may need to also pass in /p:AllowUntrustedCertificate=true.
One little addition which may not be directly related to your issue, but may be helpful for others which may see this later.
If you are building the .csproj/.vbproj file (and potentially in some scenarios where the .sln file is used) you should pass in the property /p:VisualStudioVersion=11.0. More info on this available at my blog http://sedodream.com/2012/08/19/VisualStudioProjectCompatabilityAndVisualStudioVersion.aspx
Environment: TeamCity 6.5.1 on Win2k3, BuildAgent(s) on Win2k3, Visual Studio 2k10, .NET v4, Nant 0.91
I'm completing the setup of TeamCity and am trying to lock down the BuildAgent account on the build machine(s) per our security guidelines. The build is crashing the first time "devenv.exe /build" is called via the Nant script:
Faulting application devenv.exe, version 10.0.30319.1, stamp 4ba1fab3,
faulting module msenv.dll, version 10.0.30319.1, stamp 4ba1fd94,
debug? 0, fault address 0x0000c36b.
I had no luck googling that message. However, if I change the BuildAgent Service from the Local Network Account to the Administrator account, things work. However, if I use another domain account, it fails. Also fails if I add that domain account to the local Administrators group.
Any ideas on what I'm missing? Is there a specific privilege you need to have in order for a "DevEnv /build" to work without crashing?
Yuck, I just went through this recently. First, use devenv.com, not devenv.exe. The devenv with the com extension can build a solution and send all output to the console, without using the gui. As the TeamCity agent is a service, it may not be allowed to interact with the gui at all.
Second, and I realize that this might not be possible for you (especially if you are building an MSI), but consider doing whatever you need to do to use the built in Visual Studio build runner that comes with TeamCity. It does utilize MSBuild to do its work. If you go this route and you still need devenv, then go find MSBuild Extensions Pack, which has already solved a lot of these issues with their own devenv build task.
Honestly, I ended up replacing Microsoft's installation projects with alternatives (InstallShield or WiX), and never looked back.
I'm trying to create a worker process for Azure and I'd like to test it via nUnit. I need to write a process which connect to storage and uploads data to it. The problem is I can't find any references to how you actually set up the testing framework to start dev fabric etc.
I've created the Work Processor role and then created a testing project, wired up nunit to start and for the project to pick up the test project dll. This all works fine with nUnit opening, I'm able to see the test dll and run the test.
My issue is "How do I get the dev fabric to start up when running the project through nUnit?" I'm presuming that I need to put something into the setup routine within the test project but I can't see what I should put in.
If anyone has any tips, experience etc., links to how to etc. I'd be very grateful. I'm sure that I can't be the first person who want to put Azure projects under test.
Haven't done this myself, but the DevFabric (compute and store) has a command-line interface.
You would just invoke the commdn from your test stand-up routine and it should be good to go.
CSrun.exe is the command, please see MSDN for usage reference:
http://msdn.microsoft.com/en-us/library/gg433001.aspx