custom tasks msbuild

Automate your best experience

Create MSBuild Custom Task

I Will show you how to create MSBuild custom task I know you will find many examples on the internet but if you just try most of them most properly it will not work, so I decide to post article that describe it in very simple way with source code of the success project. If you want to see a tutorial on MSBuild you can visit the following link click-here

• Create a class library project that will contain all your custom task classes
• Reference both Microsoft.Build.Framework and Microsoft.Build.Utilities
• Create a new class and name it MyTask inherit from Class Task, and override the Execute method
• Call Log.LogMessage to output a message during the build and give it the property of your class

[sourcecode language=”csharp”] using System; using Microsoft.Build.Framework; using Microsoft.Build.Utilities;

namespace CustomTask { public class MyTask : Task { public string MyProperty { get; set; }

public override bool Execute() { // Log a high-importance comment Log.LogMessage(MessageImportance.High, “The task was passed “” + MyProperty + “”.”); return true; } } } [/sourcecode]

Second part, the usage of your custom task

• Create any project,  it prefers to be class library also and remove all the code between the project element
• Edit the target to be MyTarget
• Add a reference to the assembly that contain the custom task and here what cause the problem to happen, the wrong path always make problem so my advice to you that you have to know exactly how to point to specific file and what is the different between absolute and relative path, how to out from the current folder or 2 folders and so on so forth, any way you just add the reference
• Add new Target called MyTarget and start using the task

• Open Visual studio CMD and go the project file path and run MSBuild and that’s it

To download the project just click here

You can find also the link on the MSDN that describe the custom task here

Note: Most of problem happen because the path of the dll of the custom task so if you have a problem creating your own you just use absolute path to make sure the example work and then fix the absolute path with relative path

I hope you like it.

• JetBrains Rider
• Aug 04, 2020

Implementing and Debugging Custom MSBuild Tasks

TL;DR: MSBuild is at the heart of every .NET project. It’s the system that ultimately invokes tools like NuGet or the C# compiler. Additional tools can be integrated via custom MSBuild tasks, however, working with these can be very daunting at first. Knowing a few tricks and tools, the process of implementing, packaging, and debugging a custom task can be greatly simplified. A sample project is available on GitHub .

Much of the tooling around .NET projects ends up having to integrate with MSBuild , the low-level build system in the .NET ecosystem. A few examples of these tools are:

• Refit – REST APIs are generated based on interface declarations before compilation
• Fody – IL code gets rewritten after compilation to add null-checks , merge assemblies to a single file , notify on property changes and much more
• NSwag – Swagger specifications, C#/TypeScript clients and proxies are generated from C# ASP.NET controllers as part of the build
• GitVersion – Semantic versions are calculated based on our commit history and propagated into MSBuild properties before compilation to make them part of the assembly metadata

Some of the scenarios that involve code generation could eventually move to Source Generators , which are already available in the .NET 5 previews . Source generators remove a lot of the burden of writing MSBuild tasks – and sharing workspaces – but still aren’t easy to debug:

Clearly that sets the mood for what a pleasure it is to write an MSBuild task! 😅

MSBuild Integration Options

When we want hook into the execution of MSBuild, we have several options:

• Inline Tasks – We can write code fragments directly into .targets files. They will be compiled into tasks by the RoslynCodeTaskFactory and executed by MSBuild when run. This is great for drafting ideas, but falls short in maintainability and debugging.
• Exec Tasks – Any executable can be invoked in a similar way to Process.Start . We can capture output, validate exit codes, or define regular expressions for custom error/warning messages. However, we will miss some integration points, and if we need to get complex data out of the process, we’ll have to encode it in a single line and decode it in the target .
• Custom Tasks – We can operate with MSBuild infrastructure directly, including ITask , IBuildEngine , and ITaskItem objects. This allows us to log error/warning/info events, inspect item groups with their metadata , create more object-like results, and even to support incremental builds .

Since custom tasks are the most scalable solution , we will put focus on them for the rest of this article.

Implementing the Task

From my own experience, I’d recommend to keep the task assembly small and move complex logic into their own projects. This is also the approach most of the projects mentioned above have taken. Some of the most important types for custom MSBuild tasks are ITask , IBuildEngine , and ITaskItem . In order to gain access, we need to add references for them:

Note that the MSBuild references are part of every MSBuild installation and therefore should not be deployed with our final NuGet package . In order to achieve that, we set the CopyLocal and Publish attribute for each reference to false . We will also need to remove those references from the ReferenceCopyLocalPaths item group:

As already hinted, our task assembly will likely have dependencies to other projects or NuGet packages. A while back, this would have taken a huge effort:

Meanwhile we’re at MSBuild 16, and some of the problems that Nate described in his blog have already been addressed. I am by no means an expert in properly resolving dependencies, but Andrew Arnott came up with the ContextAwareTask – originally used in Nerdbank.GitVersion – which is working out great for many folks:

As for the actual implementation, we won’t go into too much detail but focus on the most important bits . MSBuild calls the Execute method which will later delegate to ExecuteInner and its return value signals whether the task succeeded or failed. The inherited BuildEngine property allows us to log information, warning, and error messages. Users of the task can opt-in to treat warnings of the task as errors by setting the TreatWarningsAsErrors property. The StringParameter property is a required input value. The FilesParameter item group is optional and can contain a list of files. In many situations, a ITaskItem can also be a ordinary string value, like for PackageReference .

Wiring the Task

In this next step we’ll wire up the task implementation in a .targets file , which will be included in our NuGet package and automatically loaded from a referencing project. In this file – here CustomTasks.targets we’ll load the task assembly, create a new XML task element, define a couple default values, and create a new target that calls the task:

Defining the CustomTasksAssembly (Line 5) does not only help us to not repeat ourselves when we reference multiple tasks from the same assembly (Line 8), but is also great for debugging, as we’ll see later. Also note that we’re using a couple of well-known MSBuild properties like MSBuildThisFileDirectory and MSBuildThisFileName to avoid magic strings being scattered around our file. Following best practices makes renaming or relocating the task more effortless! The task invocation also uses the ContinueOnError property (Line 18) – one of the common properties available to all task elements .

Creating the NuGet Package

As already mentioned, we won’t pack the MSBuild tasks project directly, but have another project MainLibrary include the task infrastructure in its package . In order to load the CustomTasks.targets file from the previous section, we create another MainLibrary.props and MainLibrary.targets file in our MainLibrary project:

In the .props file, we’re defining a property CustomTasksDirectory that points to the directory containing our task. Note that we need to take the MSBuild runtime into account by checking MSBuildRuntimeType (Line 5-6). A project targeting netcoreapp2.1 would still use .NET Framework for running MSBuild inside Visual Studio, while the same project would use MSBuild for .NET Core when compiling via dotnet build from the command-line. I.e., it must not be subject to framework version folder structure . In the .targets file, we will import the CustomTasks.targets file:

We also add a condition to check if CustomTasksEnabled is enabled (Line 4). This little trick allows us to easily opt-out from attaching the task . Faulty MSBuild tasks have a high chance to completely break a referencing project and to cause confusion about where the error originates from:

As one of the last steps, we define the package structure in our MainLibrary.csproj project file:

It is important to remember, that to properly create the package, we first need to call dotnet publish for the supported target frameworks. The complete list of invocations should be as follows:

Debugging a Task

Let’s get to the most interesting part of how we can effectively debug MSBuild integration in a test project:

Indeed, with the console application approach , things are rather easy. On Windows we can call System.Diagnostics.Debugger.Launch() , which fires up the Just-In-Time Debugger so that we can attach to the process. By default, this will use the Visual Studio JIT Debugger , but we can also configure JetBrains Rider as the Just-In-Time Debugger . As of now, this strategy is not supported on Linux/macOS . The best workaround I’ve found is to call SpinWait.SpinUntil(() => Debugger.IsAttached) , which will wait until the debugger is actually attached.

Taking the custom MSBuild task approach , we have a bit more footwork to do. Referencing a package via PackageReference , their main .props and .targets files get automatically included . This is not the case when using ProjectReference on the same project! We could create an actual package, but that has the unpleasant side-effect of getting persisted in our global NuGet cache:

Deleting from the cache, or incrementing versions – all those are rather poor workarounds compared to a possible better development and testing experience for NuGet packages. A better alternative is to manually wire up our test project :

The .props file should be imported at the very beginning of the project file (Line 3), allowing to set default property values. Meanwhile, the .targets file should be important at the very end of the project file (Line 16), to ensure the task is run with the relevant input values. Here, we will also utilize our trick from the previous section, and set a default for CustomTasksEnabled (Line 8), which can either be overridden from the outside (hence the condition) or manually changed to test behavior in the IDE . We should also not forget about adjusting the CustomTasksDirectory property to point to the local version of our task.

With JetBrains Rider we can use run configurations to make this process more convenient. In the first configuration Publish CustomTasks , we will publish the MSBuild task project :

In a second configuration Run CustomTasks we will depend on the first one (see Before launch ), and call MSBuild.dll /t:Clean;Restore;Pack /p:CustomTasksEnabled=True to invoke MSBuild on the test project :

Note that this is the place when we need to override the CustomTasksEnabled property to execute our task. Also we should make an educated choice of which targets should be invoked . If our task integrates with the Restore target, then we really need to execute Clean before, because otherwise it may be skipped for consecutive builds.

Now that we’re all set up, we can use the Run CustomTasks configuration to finally debug our task implementation:

Troubleshooting MSBuild

Sooner or later we will run into issues with our MSBuild integration, especially regarding the .props and .targets files. We might reference a wrong property, forget about escaping, or just have a typo in our identifiers. The Project Properties dialog is a good place to start investigations and to see evaluated properties and imports for a project file:

Using the common keyboard shortcut, we can also easily copy values from grid cells . If we need even more insight, then the MSBuild Structured Log Viewer created by Kirill Osenkov can be of great help:

The Structured Log Viewer operates on binary log files , which can be created by passing /binaryLogger:output.binlog to the MSBuild invocation. Binary log files provide the highest level of completeness and verbosity , even compared to most-diagnostic level for text logs. Imports of files and execution of targets are hierarchically visualized using a tree view . Particularly when trying to find a proper target build order for our integration, we can easily check on the flattened temporal order view :

Another benefit is that when testing our task on large projects that imply a time-consuming compilation, we can replay a single task without executing all its dependencies:

For developers on Windows there is a special surprise in JetBrains Rider ! We can right-click the test project, choose Advanced Build Actions and execute Rebuild Selected Projects with Diagnostics :

Given that Structured Log Viewer can already run on Avalonia UI , maybe we can see the same feature also for macOS and Linux soon.

Acknowledgements

I want to add that much of my adventures with MSBuild are only of good nature and happy endings because my friend Martin Ullrich is such an MSBuild wizard . If you don’t follow him yet, you really should. Sorry Martin for sending more MSBuild enthusiasts your way! 🤗

Search code, repositories, users, issues, pull requests...

Provide feedback.

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly.

To see all available qualifiers, see our documentation .

• Notifications

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement . We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MSBuild loads and locks task assemblies even when using TaskHostFactory #6461

rainersigwald commented May 18, 2021 • edited

With this stack:

• Microsoft.Build.dll!Microsoft.Build.Shared.TypeLoader.LoadAssembly(assemblyLoadInfo) Line 162
• Microsoft.Build.dll!Microsoft.Build.Shared.TypeLoader.AssemblyInfoToLoadedTypes.ScanAssemblyForPublicTypes() Line 355
• Microsoft.Build.dll!Microsoft.Build.Shared.TypeLoader.AssemblyInfoToLoadedTypes.GetLoadedTypeByTypeName.AnonymousMethod__0(key) Line 326
• mscorlib.dll!System.Collections.Concurrent.ConcurrentDictionary<string, System.Type>.GetOrAdd(key, valueFactory) Line 1069
• Microsoft.Build.dll!Microsoft.Build.Shared.TypeLoader.AssemblyInfoToLoadedTypes.GetLoadedTypeByTypeName(typeName) Line 299
• Microsoft.Build.dll!Microsoft.Build.Shared.TypeLoader.GetLoadedType(cache, typeName, assembly) Line 226
• Microsoft.Build.dll!Microsoft.Build.Shared.TypeLoader.Load(typeName, assembly) Line 192
• Microsoft.Build.dll!Microsoft.Build.BackEnd.AssemblyTaskFactory.InitializeFactory(loadInfo, taskName, taskParameters, taskElementContents, taskFactoryIdentityParameters, taskHostFactoryExplicitlyRequested, targetLoggingContext, elementLocation, taskProjectFile) Line 278
• Microsoft.Build.dll!Microsoft.Build.Execution.TaskRegistry.RegisteredTaskRecord.GetTaskFactory(targetLoggingContext, elementLocation, taskProjectFile) Line 1307
• Microsoft.Build.dll!Microsoft.Build.Execution.TaskRegistry.RegisteredTaskRecord.CanTaskBeCreatedByFactory(taskName, taskProjectFile, taskIdentityParameters, targetLoggingContext, elementLocation) Line 1189
• Microsoft.Build.dll!Microsoft.Build.Execution.TaskRegistry.GetMatchingRegistration(taskName, taskRecords, taskProjectFile, taskIdentityParameters, targetLoggingContext, elementLocation) Line 689
• Microsoft.Build.dll!Microsoft.Build.Execution.TaskRegistry.GetTaskRegistrationRecord(taskName, taskProjectFile, taskIdentityParameters, exactMatchRequired, targetLoggingContext, elementLocation, retrievedFromCache) Line 538
• Microsoft.Build.dll!Microsoft.Build.Execution.TaskRegistry.GetRegisteredTask(taskName, taskProjectFile, taskIdentityParameters, exactMatchRequired, targetLoggingContext, elementLocation) Line 417
• Microsoft.Build.dll!Microsoft.Build.BackEnd.TaskExecutionHost.FindTaskInRegistry(taskIdentityParameters) Line 868
• Microsoft.Build.dll!Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.FindTask(taskIdentityParameters) Line 249
• Microsoft.Build.dll!Microsoft.Build.BackEnd.TaskBuilder.ExecuteBucket(taskHost, bucket, howToExecuteTask, lookupHash) Line 414
• Microsoft.Build.dll!Microsoft.Build.BackEnd.TaskBuilder.ExecuteTask(mode, lookup) Line 325
• Microsoft.Build.dll!Microsoft.Build.BackEnd.TaskBuilder.ExecuteTask(loggingContext, requestEntry, targetBuilderCallback, taskInstance, mode, inferLookup, executeLookup, cancellationToken) Line 179
• Microsoft.Build.dll!Microsoft.Build.BackEnd.TargetEntry.ProcessBucket(taskBuilder, targetLoggingContext, mode, lookupForInference, lookupForExecution) Line 816
• Microsoft.Build.dll!Microsoft.Build.BackEnd.TargetEntry.ExecuteTarget(taskBuilder, requestEntry, projectLoggingContext, cancellationToken) Line 499
• Microsoft.Build.dll!Microsoft.Build.BackEnd.TargetBuilder.ProcessTargetStack(taskBuilder) Line 486

It's not clear to me that we actually need a live Type object for taskfactory purposes; we should be able to get by with unloaded information like type full name. I'm not sure what point we do parameter validation though; with inheritance that might get complicated without a live type.

I'm also extremely confused by how it's taken this long to notice this. I've been giving that advice for years. Did something regress here? Behavior appears the same in 15.9 (plus the extra lock from the long-lived taskhost #3141 that wasn't fixed yet). But it took until now for someone to notice that it didn't work, which seems odd.

The text was updated successfully, but these errors were encountered:

• 👍 3 reactions
• 🎉 2 reactions

rainersigwald commented Jul 13, 2021

Sorry, something went wrong.

vritant24 commented Jul 22, 2021

Forgind commented Jul 22, 2021

Rainersigwald commented jul 28, 2021.

msbuild/src/Shared/LoadedType.cs

Line 74 in d592862

Note that if we change this to avoid the load, we will still have to do the load in the "standard" case here, losing this optimization that depends on having already done the load:

msbuild/src/Shared/TaskLoader.cs

Lines 125 to 127 in d592862

rseanhall commented Nov 12, 2021

Rainersigwald commented nov 12, 2021.

icnocop commented Mar 15, 2022

Zastai commented May 2, 2022

Rainersigwald commented may 2, 2022, zastai commented may 2, 2022 • edited.

Successfully merging a pull request may close this issue.

This browser is no longer supported.

Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.

UsingTask element (MSBuild)

• 11 contributors

Maps the task that is referenced in a Task element to the assembly that contains the task implementation.

<Project> <UsingTask>

Unlike properties and items, the first UsingTask element that applies to a TaskName will be used; to override tasks you must define a new UsingTask before the existing one.

Attributes and elements

The following sections describe attributes, child elements, and parent elements.

Child elements

Parent elements.

Environment variables, command-line properties, project-level properties, and project-level items can be referenced in the UsingTask elements included in the project file either directly or through an imported project file. For more information, see Tasks .

Project-level properties and items have no meaning if the UsingTask element is coming from one of the .tasks files that are globally registered with the MSBuild engine. Project-level values are not global to MSBuild.

In MSBuild 4.0, using tasks can be loaded from .overridetask files.

The assembly containing the custom task is loaded when the Task is first used.

The following example shows how to use the UsingTask element with an AssemblyName attribute.

The following example shows how to use the UsingTask element with an AssemblyFile attribute.

• How to: Configure targets and tasks
• Task reference
• Project file schema reference

Submit and view feedback for

Additional resources

Malicious NuGet packages abuse MSBuild to install malware

Bill toulas.

• October 31, 2023

A new NuGet typosquatting campaign pushes malicious packages that abuse Visual Studio's MSBuild integration to execute code and install malware stealthily.

NuGet is an open-source package manager and software distribution system, enabling developers to download and include ready-to-run .NET libraries for their projects.

Threat actors who target software distribution systems like npm and PyPI have recently shown interest in NuGet, which predominantly targets Windows users and has become very popular among software developers.

Hiding code with MSBuild

The latest NuGet campaign was  spotted by ReversingLabs  on October 15, 2023, utilizing different typosquatting packages to install malware.

Some of the packages seen in this campaign include:

• CData.NetSuite.Net.Framework
• CData.Salesforce.Net.Framework
• Chronos.Platforms
• DiscordsRpc
• Kraken.Exchange
• KucoinExchange.Net
• MinecraftPocket.Server
• Pathoschild.Stardew.Mod.Build.Config
• SolanaWallet
• ZendeskApi.Client.V2

The novel element in this campaign is that instead of using the standard approach of incorporating downloaders in the install scripts, these packages leverage NuGet's MSBuild integration for code execution.

NuGet's MSBuild integrations is a feature introduced in NuGet v2.5 with the goals of supporting native projects, automating the build and testing process, and giving developers the ability to define custom actions and resolve dependencies.

When NuGet installs a package containing a '\build' folder, it automatically adds an MSBuild <Import> element to the project, referencing the .targets and .props files in that folder. The build process uses these files to set configurations, properties, or custom tasks.

Although added to enhance the build and packaging process for software projects, this new NuGet integration has  raised concerns  about the security implications it introduces, as it adds a new method to automatically run scripts when a package is installed.

In the case spotted by ReversingLabs, the malicious code is hidden inside the <packageID>.targets file in the "build" directory as a <Code> property that implements the functionality of PowerShell scripts used in previous versions of the packages.

Upon execution, the code fetches an executable from an external address and runs it in a new process.

This technique was first introduced by a security researcher in 2019 to illustrate how the MSBuild process can be abused to run code when NuGet packages are installed.

"First, the string artifact in the first line of the file, 'IAmRootDemo' led us to the root of this execution technique," explains ReversingLab's Karlo Zanki in a report shared with BleepingComputer.

"Several years ago, in 2019, the  IAmRoot  package was published by  C. Augusto Proiete . The purpose of the package: 'To demonstrate that any NuGet package can run arbitrary code on your machine.'"

However, this is the first documented case of threat actors leveraging this feature in malicious NuGet packages.

Evolution of existing campaigns

ReversingLabs reports that the NuGet packages they spotted, which have been removed, were part of an ongoing campaign that started in August 2023.

However, it didn't abuse MSBuild integrations until mid-October.

Earlier versions utilized PowerShell scripts ('init.ps1') to fetch the malware payload from a GitHub repository.

This indicates that the attackers continually refine their techniques to make the attacks stealthier.

The analysts also report observing strong ties to a campaign reported by Phylum at the start of the month, where the attackers used typosquatting to mimic crypto projects and deliver SeroXen RAT. 

ReversingLabs reports that the threat actors immediately attempted to upload new packages after previous ones were removed, showing intent to continue the campaign.

Related Articles:

Hundreds of malicious Python packages found stealing sensitive data

Decentralized Matrix messaging network says it now has 115M users

Malicious Solana, Kucoin packages infect NuGet devs with SeroXen RAT

Free Download Manager releases script to check for Linux malware

Free Download Manager site redirected Linux users to malware for years

• Code Execution
• Open Source
• Previous Article
• Next Article

Post a Comment Community Rules

You need to login in order to post a comment.

Not a member yet? Register Now

You may also like:

New CVSS 4.0 vulnerability severity rating standard released

Okta hit by third-party data breach exposing employee information

Help us understand the problem. What is going on with this comment?

• Abusive or Harmful
• Inappropriate content
• Strong language

Read our posting guidelinese to learn what content is prohibited.

File : Moscow-City (36211143494).jpg

File history, file usage on commons, file usage on other wikis.

Original file ‎ (3,753 × 2,813 pixels, file size: 9.85 MB, MIME type: image/jpeg )

Summary [ edit ]

Licensing [ edit ].

• to share – to copy, distribute and transmit the work
• to remix – to adapt the work
• attribution – You must give appropriate credit, provide a link to the license, and indicate if changes were made. You may do so in any reasonable manner, but not in any way that suggests the licensor endorses you or your use.

Click on a date/time to view the file as it appeared at that time.

You cannot overwrite this file.

The following 6 pages use this file:

• User:JWilz12345/Cities-Russia
• User:Stolbovsky/Recent uploads/Moscow/2017 September 1-10
• Commons:WikiProject Aviation/recent uploads/2017 September 7
• File:MSK Collage 2015.png
• File:Moscow-City (36211143494) (crop).jpg
• File:Moscow Business Center Sep2017.jpg (file redirect)

The following other wikis use this file:

• Moskwa-Siti
• اقتصاد روسيا
• قائمة المدن حسب عدد السكان
• Rusiyanın inzibati bölgüsü
• Moskva Beynəlxalq Biznes Mərkəzi
• Rusiya coğrafiyası
• ইউরেশীয় অর্থনৈতিক ইউনিয়ন
• Moscow City
• Benutzer:Bonnatia
• Οικονομία της Ρωσίας
• Μεγαλύτερες πόλεις του κόσμου
• Lists of cities by country
• Eurasian Economic Union
• List of songs about Moscow
• User:Mattximus/sandbox5
• User:Lovewhatyoudo/sandbox
• Template:Moscow sidebar
• Anexo:Edificios más altos de Rusia
• Moskuko Nazioarteko Finantza Gunea
• Errusiako ekonomia
• مرکز بین‌المللی کسب‌وکار مسکو
• Économie de la Russie
• Moskva-City
• Lista de cidades do mundo por poboación
• जनसंख्या के आधार पर यूरोप के महानगर
• Moskovski međunarodni poslovni centar
• Portal:Europa/Redizajn2
• Portal:Europa/Slika/4
• Szerkesztő:Milei.vencel/list
• Szerkesztő:Milei.vencel/List of largest cities
• 世界の都市圏人口の順位
• 모스크바 국제 비즈니스 센터
• Maskvos tarptautinis verslo centras
• Moskiewskie Międzynarodowe Centrum Biznesowe

View more global usage of this file.

This file contains additional information such as Exif metadata which may have been added by the digital camera, scanner, or software program used to create or digitize it. If the file has been modified from its original state, some details such as the timestamp may not fully reflect those of the original file. The timestamp is only as accurate as the clock in the camera, and it may be completely wrong.

Structured data

Items portrayed in this file, copyright status, copyrighted, copyright license, creative commons attribution 2.0 generic, coordinates of the point of view, 55°44'54.640"n, 37°33'12.157"e, 25 july 2017, source of file, file available on the internet, exposure time, focal length, 4.73 millimetre, instance of.

• Aerial photographs of Moscow
• Moscow International Business Center photographed in 2017
• July 2017 in Moscow
• Files with coordinates missing SDC location of creation
• Flickr images reviewed by FlickreviewR
• Files from deensel Flickr stream
• Russia photographs taken on 2017-07-25
• Images with annotations
• Pages with maps

Navigation menu