We recently swapped to NetCore projects and made needed changes to the pipeline. The pipeline task PublishSymbols#2 doesn't seem to be publishing symbols for our NuGet packages. At least, the Debugger isn't working anymore. Should I be using another task? Are my parameters wrong?
The pipeline sends out a warning that
##[warning]No files selected for indexing.
It also has the log file line
[Symbol App][INFO] 2021-07-02T11:41:51.7320634+00:00 Published 1 files.
projectsNuGet: |
**/ParkInd_Modular_CommonPlugins.#(csproj|pdb)
- task: PublishSymbols#2
displayName: Publish debug information to symbol servers
inputs:
SearchPattern: |
$(projectsNuGet)
!*.csproj
!**/obj/**
SymbolServerType: 'TeamServices'
The code didn't work because my dll had a different name than my csproj. Apparently the name of a dll is based on the AssemblyName not the csproj name. It makes sense.
Related
Our organization has two separate collections
Application Development
Foobar Inc (Project)
Repo / Build pipeline (Pipeline)
External Applications (Collection)
External Applications (Project)
Artifacts
XYZ_SharedPackages (Nuget feed)
When I run the restore command for a project in Appliction Development for the Foobar Inc project I get
"C:\agent\_work\76\s\Foobar_Inc\Foobar_IncUI\Foobar_IncUI.csproj" (Restore target) (1) ->
(Restore target) ->
C:\Program Files\dotnet\sdk\6.0.200\NuGet.targets(130,5): error : Unable to load the service index for source
http://svp042iis/tfs/Application%20Development/_packaging/XYZ_SharedPackages/nuget/v3/index.json.
[C:\agent\_work\76\s\Foobar_Inc\Foobar_IncUI\Foobar_IncUI.csproj]
C:\Program Files\dotnet\sdk\6.0.200\NuGet.targets(130,5): error : Response status code does not indicate
success: 404 (Not Found - The feed with ID 'XYZ_SharedPackages' doesn't exist. (DevOps Activity ID: 5C76EC84-96B7-4125-BA30-296CF33B1754)).
[C:\agent\_work\76\s\Foobar_Inc\Foobar_IncUI\Foobar_IncUI.csproj]
The 404 error is coming from the source not existing, however I selected that feed by going into the restore command and selecting that option under feeds to use. My question is, does anyone know if it's possible to share across collections in dev ops.
If your two organziations are NOT in same AAD, you can follow below methods:
Method1:
You can use a NuGet authenticate task and a powershell task to run the nuget install command in the pipeline with the Feed URL of the target feed.
Create a Nuget Service connection to the target organization.
Target feed URL:https://pkgs.dev.azure.com/{orgname}/_packaging/{feedname}/nuget/v3/index.json, The password is PAT.
2.Add NuGet authenticate task before your restore.
Use the powershell task in line script.The in line script :
nuget install {package name} -version {package version} -Source https://pkgs.dev.azure.com/{orgname}/_packaging/{feedname}/nuget/v3/index.json.
It will restore the package successfully.
Method 2:
Directly use a powershell task with inline script:
nuget install {package name} -version {package version} -Source https://pkgs.dev.azure.com/{orgname}/_packaging/{feedname}/nuget/v3/index.json.
The two Environment Variables needs to be set:
• NUGET_CREDENTIALPROVIDER_SESSIONTOKENCACHE_ENABLED=true
• VSS_NUGET_EXTERNAL_FEED_ENDPOINTS= {"endpointCredentials": [{"endpoint":"https://pkgs.dev.azure.com/{orgname}/_packaging/{feedname}/nuget/v3/index.json", "username":"optional", "password":"$(PAT)"}]}
If your two organizations are in same AAD, you can follow below steps：
Please check the permissions in Feed Settings -> Views. Then change the access permissions for Local view in more options-> edit, choose “All feeds and people in organizations associated with my Azure Active.
Setup upstream resource :
On the upstream feed, add project collection build service account as contributor or collab or owner role.
i got this weird error, where every output in the console with symfony creates some extra characters. The following is the output after a basic symfony in the console.
$ symfony
←[32mSymfony CLI←[39m version ←[33mv4.22.0←[39m (c) 2017-2021 Symfony SAS
Symfony CLI helps developers manage projects, from local code to remote infrastructure
These are common commands used in various situations:
←[33mWork on a project locally←[39m
←[32mnew←[39m Create a new Symfony project
←[32mserve←[39m Run a local web server
←[32mserver:stop←[39m Stop the local web server
←[32msecurity:check←[39m Check security issues in project dependencies
←[32mcomposer←[39m Runs Composer without memory limit
←[32mconsole←[39m Runs the Symfony Console (bin/console) for current project
←[32mphp, pecl, pear, php-fpm, php-cgi, php-config, phpdbg, phpize←[39m Runs the named binary using the configured PHP version
←[33mManage a project on Cloud←[39m
←[32mlogin←[39m Log in with your SymfonyConnect account
←[32minit←[39m Initialize a new project using templates
←[32mlink←[39m Link current git repository to a SymfonyCloud project
←[32mprojects←[39m List active projects
←[32menvs←[39m List environments
←[32menv:create←[39m Create an environment
←[32mtunnel:open←[39m Open SSH tunnels to the app's services
←[32mssh←[39m Open an SSH connection to the app container
←[32mdeploy←[39m Deploy an environment
←[32mdomains←[39m List domains
←[32mvars←[39m List variables
←[32muser:add←[39m Add a user to the project
Show all commands with ←[32msymfony.exe help←[39m,
Get help for a specific command with ←[32msymfony.exe help COMMAND←[39m.
As you can see, I get this ←[33m here and there. Any help is gratefully accepted. Please let me know if you need any additional information from me.
$ bin/console --version
Symfony 5.2.1 (env: dev, debug: true)
I am attempting to make a migration from D7 to D8 using Migrate Manifest. I have all the migrate modules installed (i.e. the 3 core migrate modules, Migrate Upgrade, Migrate Plus, Migrate Tools and Migrate Manifest). I followed the directions at this link: https://www.drupal.org/node/2350651 to prepare my manifest file. This is the relevant part of my resulting yaml file (truncated for brevity):
- block_content_body_field
- block_content_entity_display
- block_content_entity_form_display
- block_content_type
- d7_block
- d7_custom_block
When I ran the migrate-manifest via Drush, as specified by the directions in the link above, I received an error declaring a parse error pointing to the first line in the yaml list. This is the exact error: Unable to parse at line 1 (near " - block_content_body_field").
I tried several debugging steps:
I checked a yaml linter to see whether my file was properly formatted. My file passed the test.
I moved the block migrations below the ones that are prefixed with a 'd7' to match the example in the link.
I attempted a piecemeal migration of a file from my list of migrations, it worked.
I tried to alter the spacing on the list items.
All these steps failed to resolve the issue I am seeing.
I am unsure what other debugging steps I should take. All the above failed to resolve my issue.
Any ideas would be appreciated.
I've created a Release definition in TFS 2015 update 2 as seen below:
I want to use this as part of my CI process. The build and unit tests are executed on a dedicated BizTalk build server for each check-in. Executed nightly, this (currently problematic) release should deploy to an "DevTest" BizTalk server and execute integration tests.
All is good up to the last "Run Functional Tests" task. So, the BizTalk applications are removed, then deployed to the target server in the correct order. The "IntegrationTests" assembly contains a few Specflow tests which make use of the Transmock framework (http://transmock.codeplex.com/). Steps for these tests are contained within an assembly called "Common.Commponents". This is referenced from a test assembly called "Finance.IntegrationTests.dll". The tests pass when run on my Dev VM. However, when executed by the "Run Functional Tests" task, I get the following error:
Test method Finance.IntegrationTests.ASC_BacsFeature.BacsFileMoved threw exception: NUnit.Framework.InconclusiveException: No matching step definition found for one or more steps.using System;using TechTalk.SpecFlow;namespace MyNamespace{ [Binding] public class StepDefinitions { [Given(#"an output path specified by sso app '(.)' and setting '(.)'")]public void GivenAnOutputPathSpecifiedBySsoAppAndSetting(string p0, string p1){ ScenarioContext.Current.Pending();} [Given(#"the inpu
I have set the App.config of my test project to use MsTest as seen below:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<configSections>
<section name="specFlow" type="TechTalk.SpecFlow.Configuration.ConfigurationSectionHandler, TechTalk.SpecFlow"/>
</configSections>
<specFlow>
<!-- For additional details on SpecFlow configuration options see http://go.specflow.org/doc-config -->
<unitTestProvider name="MsTest"/>
<stepAssemblies>
<stepAssembly assembly="LCC.Integration.Common.Components" />
</stepAssemblies>
</specFlow>
<startup><supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.5.1"/></startup></configuration>
It seems that when the tests are executed remotely, NUnit is used rather than MSTest.
The "Common.Components.dll" is successfully deployed to the GAC earlier in the release via GacUtil /I, so I'm not sure why it can't be found?
I've tried running the tests directly on the remote server. I RDP'd on, then opened a command window and ran "vstest.console Finance.IntegrationTests.dll". I then received warnings that the test input files could not be found, followed by errors because "Could not load file or assembly 'nunit.framework'".
I think the problem is, App.config of the Integration Test assembly is not being used when the tests are executed remotely. This explains why it tries to use NUnit rather than MSTest and also why it is unable to bind to the common steps - because their location is given in the node.
Does anyone know how I can make the App.config be used when testing remotely?
There were a couple of issues. I'd forgotten that the app.config would be compiled into finance.integrationtests.dll.config. References to dlls in the config needed to have the full strong name rather than just the name.
I'm trying to deploy an ASP.NET web application to Azure. It's hybrid Web Forms, MVC, and WebAPI, and there are a TON of aspx/ascx files, such that they really need to be precompiled or every deploy will render the site sluggish for awhile.
I am trying to deploy via SCM integration with GitHub via kudu, with precompiled views, all merged to a single assembly.
Note that:
Deploy works fine with precompilation disabled.
Deploy works fine from Visual Studio
Build works fine if I copy the msbuild command from the Azure log, replace the relevant paths, and run it locally on my Windows 8.1 machine.
I've set up the Advanced Precompile settings as:
Don't allow precompiled site to be udpatable
Don't emit debug information
Merge all pages and control outputs to a single assembly = AppViews.dll
Here's the .deployment file for Azure
[config]
project = WebSite/WebSite.csproj
SCM_BUILD_ARGS=/p:Configuration=Release;PublishProfile=azure-prod /v:n
You notice I'm sending the verbosity /v to "normal" for extra diagnostic information.
Here is info I get toward the tail of the deployment log:
AspNetPreCompile:
D:\Windows\Microsoft.NET\Framework\v4.0.30319\aspnet_compiler.exe -v \ -p D:\home\site\repository\WebSite\obj\Release\AspnetCompileMerge\Source -c D:\home\site\repository\WebSite\obj\Release\AspnetCompileMerge\TempBuildDir
GenerateAssemblyInfoFromExistingAssembleInfo:
Creating directory "obj\Release\AssemblyInfo".
D:\Windows\Microsoft.NET\Framework\v4.0.30319\Csc.exe /out:obj\Release\AssemblyInfo\AssemblyInfo.dll /target:library Properties\AssemblyInfo.cs
AspNetMerge:
Running aspnet_merge.exe.
D:\Program Files (x86)\Microsoft SDKs\Windows\v8.0A\bin\NETFX 4.0 Tools\aspnet_merge.exe D:\home\site\repository\WebSite\obj\Release\AspnetCompileMerge\TempBuildDir -w AppViews.dll -copyattrs obj\Release\AssemblyInfo\AssemblyInfo.dll -a
aspnet_merge : error 1003: The directory 'D:\home\site\repository\WebSite\obj\Release\AspnetCompileMerge\TempBuildDir' does not exist. [D:\home\site\repository\WebSite\WebSite.csproj]
Done Building Project "D:\home\site\repository\WebSite\WebSite.csproj" (Build;pipelinePreDeployCopyAllFilesToOneFolder target(s)) -- FAILED.
Build FAILED.
It looks like aspnet_compiler.exe runs, but doesn't do what it's supposed to, which is why the TempBuildDir directory (supposed to be the output of the compiler) does not exist in time for the AspNetMerge target. Contrast that with my system, where that directory DOES in fact exist, containing the marker aspx/ascx/etc. files, static content, a PrecompiledApp.config file, and a whole mess of stuff in the bin directory.
aspnet_compiler.exe has an -errorstack flag but it's not clear to me how I could get MSBuild to add this just via the .deployment file, or even if that app is really even throwing an error.
I could just deploy via Visual Studio, but I would really like to take advantage of the SCM integration so I can just push to my prod branch and let it go. Any suggestions?
I replied on https://github.com/projectkudu/kudu/issues/1341, but copying my answer here in case someone lands here...
Way back, we had found that aspnet_compiler.exe was not working within Azure Websites due to how it dealt with the profile folder. We made a change at the time that's a bit of a hack but got us going: we turned it into a no-op, by pointing HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\aspnet_compiler.exe to our own dummy exe (D:\Program Files (x86)\aspnet_compiler\KuduAspNetCompiler.exe).
But trying it now, it appears to work correctly today, likely thanks to improvements in the Azure Websites hosting environment. So we will try getting rid of this hack and doing a full test pass to make sure it doesn't cause any major regressions. If all goes well, we can get that into production, which should enable those scenarios.
In the short term, you may be able to work around this by having your build script:
copy aspnet_compiler.exe from D:\Windows\Microsoft.NET\Framework\v4.0.30319 into your own site files, but under a different name (e.g. aspnet_compiler2.exe)
convince msbuild to use that one
Note: This GitHub issue on projectkudu will eventually make this solution obsolete, but for the meantime, that issue is filed as Backlog, and this works right now.
Thank you thank you David Ebbo. With this information, I was able to bootstrap my build to work for the short term.
First, I downloaded the aspnet_compiler.exe from the Azure instance using the Diagnostic Console available at https://{WEBSITE_NAME}.scm.azurewebsites.net/DebugConsole and added that to my own repository. This way there's no question about any difference between 32/64-bit, etc. I renamed it to azure_aspnet_compiler.exe in my repository.
Second, the AspNetCompiler task doesn't give you the option to change the tool name. It's hardcoded, but as a virtual property so it's overrideable. So I had to create my own task class, and package it in its own assembly, which I built in Release mode and also included in my repository.
public class AzureAspNetCompiler : Microsoft.Build.Tasks.AspNetCompiler
{
private string _toolName = "aspnet_compiler.exe";
protected override string ToolName
{
get { return _toolName; }
}
public string CustomToolName // Because ToolName cannot have a setter
{
get { return _toolName; }
set { _toolName = value; }
}
}
Next I needed to replace the AspNetPreCompile task in MSBuild, but I couldn't figure out how to do that directly. But that task wasn't doing anything anyway, so why not just run right after it?
I added this to the top of my Website.csproj file to import the DLL containing the AzureAspNetCompiler class. Note that the path is relative to the Website.csproj file I'm editing.
<UsingTask TaskName="AzureBuildTargets.AzureAspNetCompiler"
AssemblyFile="..\DeploymentTools\AzureBuildTargets.dll" />
Then I added this right below it, which is basically stealing the MSBuild target definition of AspNetPreCompile from C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\Web\Transform\Microsoft.Web.Publishing.AspNetCompileMerge.targets, with some of the property setting stuff near the top of it left out (because the original task will do that for us anyway.) Just take note of the ToolPath and CustomToolName values at the bottom of the (renamed) AzureAspNetCompiler element.
<PropertyGroup>
<!--Relative to solution root apparently-->
<LocalRepoDeploymentTools>.\DeploymentTools</LocalRepoDeploymentTools>
<AzureAspnetCompilerPath>$([System.IO.Path]::GetFullPath($(LocalRepoDeploymentTools)))</AzureAspnetCompilerPath>
</PropertyGroup>
<Target Name="NoReallyAspNetPreCompile" AfterTargets="AspNetPreCompile">
<AzureAspNetCompiler
PhysicalPath="$(_PreAspnetCompileMergeSingleTargetFolderFullPath)"
TargetPath="$(_PostAspnetCompileMergeSingleTargetFolderFullPath)"
VirtualPath="$(_AspNetCompilerVirtualPath)"
Force="$(_AspNetCompilerForce)"
Debug="$(DebugSymbols)"
Updateable="$(EnableUpdateable)"
KeyFile="$(_AspNetCompileMergeKeyFile)"
KeyContainer="$(_AspNetCompileMergeKeyContainer)"
DelaySign="$(DelaySign)"
AllowPartiallyTrustedCallers="$(AllowPartiallyTrustedCallers)"
FixedNames="$(_AspNetCompilerFixedNames)"
Clean="$(Clean)"
MetabasePath="$(_AspNetCompilerMetabasePath)"
ToolPath="$(AzureAspnetCompilerPath)"
CustomToolName="azure_aspnet_compiler.exe"
/>
<!--
Removing APP_DATA is done here so that the output groups reflect the fact that App_data is
not present
-->
<RemoveDir Condition="'$(DeleteAppDataFolder)' == 'true' And Exists('$(_PostAspnetCompileMergeSingleTargetFolderFullPath)\App_Data')"
Directories="$(_PostAspnetCompileMergeSingleTargetFolderFullPath)\App_Data" />
<CollectFilesinFolder Condition="'$(UseMerge)' != 'true'"
RootPath="$(_PostAspnetCompileMergeSingleTargetFolderFullPath)" >
<Output TaskParameter="Result" ItemName="_AspnetCompileMergePrecompiledOutputNoMetadata" />
</CollectFilesinFolder>
<ItemGroup Condition="'$(UseMerge)' != 'true'">
<FileWrites Include="$(_PostAspnetCompileMergeSingleTargetFolderFullPath)\**"/>
</ItemGroup>
With this in place, everything works as I would expect it to.