I have designed a selenium framework taking the concept of POM(Page Object Model). I want to create a generic file of that framework keeping the required dll's so that it can be used by the manual testers within the team to automate other applications.
You can package the framework aspect as a NuGet package. The package can then be ingested by the other projects that require it.
See: https://learn.microsoft.com/en-us/nuget/create-packages/creating-a-package for how to create NUGet packages.
See: https://learn.microsoft.com/en-us/nuget/quickstart/install-and-use-a-package-in-visual-studio for how to use NuGet packages.
Each test project can then include that NuGet package and implement it's own page object model classes for the specific application they are testing.
Related
I want to produce a set of NuGet packages written in C#.
These packages are class libraries, referencing each other in the way like:
MyGreatPackage.Core - no references
MyGreatPackage.Feature1 - references the core
MyGreatPackage.Feature2 - also references the core
MyGreatPackage.Feature2.SubFeature1 - references the Feature2 package and, respectively, the core
During the development stage, there is often a lack of real-world use-cases, so I decided to develop those packages as a part of a real project.
To implement it, I extract those packages as a git submodule(s) and connect them to the repository of the main application.
As a result, there is a .net solution like that:
MyApp.sln
MyApp.Host.csproj
MyApp.ClassLibrary1.csproj - references MyGreatPackage.Core.csproj
MyGreatPackage.Core.csproj - in the submodule
MyGreatPackage.Feature1.csproj - in the submodule, references MyGreatPackage.Core.csproj
MyGreatPackage.Feature2.csproj (references the core csproj)
MyGreatPackage.Feature1.SubFeature1.csproj (references the feature1 csproj)
Everything goes smoothly here, as I can develop both the app and the packages.
But, when it comes to the distribution stage, this configuration doesn't seem to work, as I can't simply push the submodule contents to the NuGet and replace the submodule references with the NuGet references.
The problem is that the Feature1 package when prepared for pushing to the NuGet, should have a reference to the MyGreatPackage.Core package and not a reference to the csproj. Also, the Feature2 package and subfeature1 package.
So how should I prepare this setup for both the development and the distribution stage?
I don't know a trivial answer to your question. But here are some possibilities:
Use some kind of tool that easily allows you to switch between project references (for working locally, being able to easily debug code, etc.) and NuGet references (for publishing your applications). RicoSuter/DNT has a switch-to-projects command that does exactly this.
Always use NuGet package references, and publish new versions whenever you need it: either to a local or to a private NuGet feed. You can debug NuGet packages with the use of tools like SourceLink, or punctually include projects. Depending how tightly coupled your projects are and the stage of development you're at, this option can be more or less viable.
The poor's man alternative to the first one when using the second approach: having a git stash that includes those projects in the solution and replaces the NuGet references with the project ones. If you work on your own, this can be an option to sporadically change to project references and debug something. If used often, this can be a pain due to those change being accidentally commited, etc.
I have an old project that runs on ASP.NET Core 2.1. The project has dependencies folder in which we have
assemblies
packages(nuget packages)
SDK
I am little bit confused by their usage and what does dependencies folder mean.
As far I know
assemblies are .net libraries that referenced into this project and it has a global scope in solution and cant be update until you manually update them.
nuget packages are installed using nuget package manager and are managed and updated when a new update but nuget package has only project scope.
sdk is like a set of tools that is used same like nuget package I think.
Here is the screenshot showing the dependencies format
.net core class library 2.1 Dependecies image
Another thing is that I am creating a new project when I add .net core class library. I have dependecies folder but it's missing
assemblies
packages(nuget packages)
SDK
but it has a new folder called framework
.net core 3.0 class library dependency image
I think I have to manually add these packages in my project. And what's the difference between these three?
Assemblies:- When we compile our source code then assembly gets generated in Visual Studio. Assembly consists of two parts Manifest and IL(Intermediate Language). Manifest contains assembly metadata means assembly's version requirements, security identity, names and hashes of all files that make up the assembly.
Packages:- A package is a container for the definitions of UML elements such as classes, use cases, and components. A package can also contain other packages. In UML Model Explorer, all the definitions inside a package are nested underneath the package.
Nuget Packages:- NuGet packages are pre-defined pieces of code which are reusable for other developers. You can add a NuGet package to your project and use it's functionality wherever you want in your project. We can also say that NuGet behaves like a platform, where developers can create and share code with the world.
SDK:-A SDK(software development kit) is a collection of APIs(Application Programming Interface) that you can reference as a single item in Visual Studio. The Reference Manager dialog box lists all the SDKs that are relevant to the project. When you add an SDK to a project, the APIs are available in Visual Studio.
Packages can not be added manually
here is the link in which it's been clearly explained how to add packages in visual studio:-
https://learn.microsoft.com/en-us/nuget/quickstart/install-and-use-a-package-in-visual-studio
.NET Core allows using project references' nuget packages e.g.
MainProject
-LocalRef1
-LocalRef2
-Newtonsoft.Json
MainProject has a direct reference to LocalRef1 which has a direct reference to LocalRef2 and LocalRef2 has the nuget package Newtonsoft.Json installed.
In MainProject, not only are we able to access LocalRef2 members but also the Newtonsoft.Json package.
In .NET Framework we'd need to reference the projects and nuget package directly to access them.
Why has this changed? Is there any documentation describing how this works?
It seems to only work with local projects as in, we can't access nuget packages referenced in other nuget packages.
This can cause a lot of issues and increase complexity as it adds 'virtual' dependencies to projects, not to mention how easy it is to create circular references.
Is there a recommended set of best practices?
I would like to know how I can share c# source codes between two (or more) .NET Core projects (commandline projects!).
As far as I understand, I can not link to source files in different directories in xproj/project.json based projects. I noticed that it now seems to be recommended to create nuget packages for everything. But is it really necessary for me to setup a private repository and create a nuget package only to be able to share some common source units?
VS2015 contains a template for .NET Core library which may be suitable for building a shared lib. Is it possible to link this lib to a project without a nuget package?
.NET Core Library is an excellent solution for you.
Do it the same way as in standard C# solution - just create the project and reference this project or add a reference to DLL file.
You don't need to use a Nuget, for your own purpose. Nuget packages could be useful to distribute your dll outside.
Clarification:
I miss one point - I'm using VS2015, but I have included Class Library project in my solution, and I'm referencing by project, not by DLL file, and this works fine in ASP.Net Core.
I also have a different project, where referencing DLL file directly working fine, but this is the previous version of ASP.NET app (not Core) - seems NET Core doesn't support this way like as the previous version (yet?).
Sorry for confusing you, sometimes it's too many technologies ;)
So could you just include ClassLibrary project into solution with your project and refer it as a project?
I have achieved this by using source control to branch from my commonly used projects in each new solution, and again merging back to the master branch if I make any changes.
Alternatively, baring in mind that NuGet is only an archived collection of files, you could keep this NuGet package locally, or even create a Template for Visual Studio that has the common libraries by default.
There are a wide range of possibilities that are down to your preference, and current environment state (I.E: Able to setup Source Control, or a package repository).
I'm making a complex application and I would create more little packages to include. I have installed a nuget package "CreateNugetPackageFromProjectAfterEachBuild" that create or update automatically a package of my application. In this moment I create two types of package Debug and Release but from VS15 I see only one package to install. Why? Is the correct way to work?
Thank you!
It's not clear from your question, what exactly you want to create NuGet packages for.
In any case, it makes no sense to have separate Release and Debug versions of packages. You could separate them by version, though:
have stable releases built as Release
have prereleases built as Debug
Make sure that each NuGet package you build has a different version, otherwise you'll cause yourself a lot of grief. NuGet has no way to differentiate between different packages with the same version. You can only update a package to a different version and individual versions are cached. It's best you create and publish new package versions from a build server, not directly from a development environment to avoid confusion.
Also, keep in mind that you should really only be using NuGet packages for libraries which have an independent lifecycle and are used in multiple projects. You will want stabilize a library before creating a new version of the package and then stick with this version in your application until you have a new stable version of the library ready.
If your libraries are more tightly coupled to the application - they don't have a separate lifecycle and you tend to modify them together with the application, then referencing them in the application as a NuGet package is not that good of an idea. You're better off just having both the libraries and the application as part of the same solution.