I am developing a web application which started life by running dotnet new angular (Clear blog explanation of usage).
To extend the functionality of the default code I started developing a Web API. I added 3 new .Net Core Library Projects named Shared, Scheduling and Scheduling_Tests.
Some Domain Model classes were defined in Scheduling, some base classes were defined in Shared and finally some NUnit tests were defined in ShedulingTests.
When I build the Solution, 2 new folders appear in my Web Application project: Shared and Scheduling. I also get build errors like the following:
Error CS0579 Duplicate 'System.Reflection.AssemblyCompanyAttribute'
I'm not sure where to go with this one, any advise would be very welcome.
This happens because the new .NET tools automatically create the attributes and add them to the assembly, so they now appear twice in the build.
There are two ways to fix it:
Delete AssemblyInfo.cs
Keep AssemblyInfo.cs, but add tags to your CSProj file to suppress the attributes in AssemblyInfo.
For example:
<PropertyGroup>
<TargetFramework>netstandard2.0</TargetFramework>
<GenerateAssemblyCompanyAttribute>false</GenerateAssemblyCompanyAttribute>
<GenerateAssemblyFileVersionAttribute>false</GenerateAssemblyFileVersionAttribute>
<GenerateAssemblyVersionAttribute>false</GenerateAssemblyVersionAttribute>
<GenerateAssemblyConfigurationAttribute>false</GenerateAssemblyConfigurationAttribute>
<GenerateAssemblyDescriptionAttribute>false</GenerateAssemblyDescriptionAttribute>
<GenerateAssemblyProductAttribute>false</GenerateAssemblyProductAttribute>
<GenerateAssemblyTitleAttribute>false</GenerateAssemblyTitleAttribute>
</PropertyGroup>
(Thanks to https://johnkoerner.com/csharp/dealing-with-duplicate-attribute-errors-in-net-core/)
Have you check if there is any AssembleyInfo.cs file available in your project? If yes, then try to delete it and rebuild your project.
Related
I've recently been trying to implement automated unit test within my Jenkins pipeline using the nunit3-console.exe, for multiple Test projects that implement Microsoft and Asp.Net related functionnalities within their set-up methods.
The test projects are in Net 5.0 and trying to run them will give me this error:
1) SetUp Error : MyProjectPath
System.IO.FileNotFoundException : Could not load file or assembly 'Microsoft.Extensions.DependencyInjection.Abstractions, Version=5.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60'. The specified file could not be found.
at MyProjectTest.StartTest()
This is obviously not the only missing assembly, as it requires many of the Microsoft.Extensions and Asp.Net related dll to functions. Manually supplying said DLLs to the Test folder directory does allow the command to properly run, but this is obviously not a great solution in the long run. Supplying the missing assemblies to the GAC would also fix the problem, but only as long as we don't update any of our packages.
What would be the intended workflow when a Test requires such DLLs? Where should they be placed so that they can easily be maintained and/or replaced after updates? I've tried using the .Net Core console runner hoping it might include these DLLs as well.
Thanks a lot for your help!
https://github.com/nunit/nunit-console/releases
Use the NUnit.ConsoleRunner.NetCore.
Here's the relevant part of my C# library csproj file
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFrameworks>net46;net48</TargetFrameworks>
<Platforms>AnyCPU;x64</Platforms>
<GenerateAssemblyInfo>false</GenerateAssemblyInfo>
As the question states, my Azure CI build pipeline completes successfully, but I'm noticing that the Test task in my pipeline takes only 1 second - and that is due to the discovery of any 'test' .dll's is failing to find anything.
I am quite certain that it's due to my outdated test DLL discovery paths
**\$(BuildConfiguration)\*test*.dll
!**\obj\**
The above is what USED to work, when there was only 1 target framework moniker.
Now that I'm trying to support multiple frameworks, I am wondering if there's a slick way to indicate that by tweaking these discovery paths (some type of wildcard technique that I can use everywhere, across different Azure DevOps projects)
I finally discovered that there is no magic discovery path that really works
My old pipeline was using Visual Studio Test task from the days when it was a traditional .NET Framework application
When I changed my .csproj to conform to the new SDK format (even though I was still building .NET Framework apps) I should have changed to a different type of task for doing the tests...
Changing to dotnet test did the trick. It has a different approach. Instead of wanting paths to compiled DLLs, it starts by wanting a pattern to help it find the PROJECT file
I use android studio for creating android apps. While designing the UI I mostly find myself copy pasting my custom made components to test different things out and to see how would they look when I actually populate the view with my component using some adapter. But when I duplicate my components I manually have to update there id's and other attributes in XML according to needs. But those changes mostly have some sort of pattern which I can always define using a regular expression.
So, in short is there any tool for android studio that can help me copy/paste XML by defining some pattern via regex or something else ?
Or should I see this as an opportunity to create my own plugin and start coding right away.
Android Studio (Version 3.3+) supports Live Templates, that you can make as per your use. These can be for .java as well as .xml file formats. See this official Android Developer Youtube channel.
More resources regarding templates in Android Studio:
How to make your own file templates in Android Studio - This is
a multi-part post.
Supercharging your app development speed with
custom file templates
A collection of some Android Studio Live
Templates - This is a Github repo.
You can also try to make repeatedly used classes, activities etc into a library package and reuse them across your projects. Add some tests to them to make sure they work as intended and with some CI/CD scripting and gradle plugins (like gradle-use-latest-versions-plugin) you can have them automatically upgrade to use latest dependency versions etc. Then all you'd need to do is pull them from a repository or include them as a library in your projects to reduce code redundancy.
Hope this helps.
Currently working on a series of projects that are contained within one solution in VS2017. Each project is a specflow project, within one solution. I would like to setup the Hooks.cs file such that it's valid for any test within the entire solution, not just the project. I'd also like to make step definitions from one project available to the other projects as a base or utility step definition.
How would I go about structuring specflow to make this possible?
You can use steps and hooks from different assemblies.
You can add in the configuration a list of additional step assemblies like this:
<specFlow>
<stepAssemblies>
<stepAssembly assembly="MySharedBindings" />
</stepAssemblies>
</specFlow>
The documentation is here: https://specflow.org/documentation/Use-Bindings-from-External-Assemblies/
But there are some known problems with it:
IntelliSense and Syntax Highlighting has some problems (https://github.com/techtalk/SpecFlow/issues/838)
Hooks could be registered double (https://github.com/techtalk/SpecFlow/issues/1004)
Historical context:
We have a project consisting of following parts:
Host application (C++)
Scripting Engine library (also written in C++)
A lot of C++ plugins (around 30+)
A lot of scripts that tie all the stuff together...
From version to version some plugins are added and some are removed.
Till now we used Visual Studio solution (*.sln) to contain all the projects (*.vcxproj) for Host application, Scripting Engine library and plugins (one *.vcxproj per plugin!).
To share sources/projects we use proprietary source control system, and till now once we merged updates from the server (some plugin projects are added and some plugin projects are removed) all the project tree in the VS were refreshed thanks to "reload" feature (no action was required from developer to see and build updated source tree).
The problem:
Now our senior management decided to switch to Eclipse CDT/MinGW pair and we faced the issue that Eclipse Workspace is not the same thing as Visual Studio *.sln ...
Now when some plugin project folder appears or some plugin project folders disappears corresponding workspace items do not update accordingly.
Thus from now every developer has to use File>Import...>General>"Existing projects into workspace" File/"Open Projects from File System" to add new projects to own Workspace manually once they were added by other developer to the source control.
Also one has to manually remove from own Workspace those plugin projects that were deleted from source control...
This is a great contrast with what we previously had with Visual Studio where "reload" feature automatically updated project/source tree (just bacause all the information arrived with *.sln/*.vcxproj from server).
Our first option was to place Workspace\.metadata etc stuff to source control (as we previously did for *.sln files) but "that is not the way how Eclipse Workspace is designed to be used" (this is even not possible just because paths in .metadata\* are absolute and tons of Workspace\* stuff it is not mergeable at all)
Question:
Is there some way to automatically syncronize Eclipse CDT Workspace with project set obtained from source control. Like just press some (hidden?) magic "refresh" button (in special plugin to install or something like that) and all the new projects will be automatically added to the source tree in the Workspace and deleted projects will also disappear automatically, wothout need to use all those "Import" wizards, and withot need to remove deleted projects manually?
May be there is a special "Container" project type in Eclipse to play the same role as *.sln did in Visual Studio or something like that?
May be other options available?... Overall intention is not in replacing *.sln by some Eclipse equivalent but to support similar workflow when bunch of plugin projects is managed as a whole and project set "refresh" to be simple operation that does not require from each person in the team to manually track projects appeared/disappeared in that set.
Have you looked at using CMake to generate the Eclipse project files? You can then import those into an Eclipse workspace.
Its not automatic, but if you create separate CMakeLists.txt files for each part, then you can easily comment the include of that part in the main CMakeLists.txt file and regenerate the project files when you only want to load subset of the project.
https://cmake.org/Wiki/Eclipse_CDT4_Generator
Should you ever want to change back to VS or to another IDE CMake can generate project files for that too.
I've personally only used CMake to generate VS-solutions and Unix make files so I can't vouch for how well this works.
HTH.
On side note, why did management decide that Eclipse should be used instead of Visual Studio? It sounds like a poor decision without factual grounds or impact research prior to the decision being made.
Was it because Eclipse is free? Did they consider what reduced developer productivity costs?