Webtest - missing dll - c#

When I creating webtests I want to add "Web Test Plug-in" I get message box with information that one of my nuget library is missing.
Whole my solution is compilable and this "missing" library exists as entry in csproj and config files. After compilation of test project this library is inside "bIn" folder. I check under dotPeek version, publicToken etc is correct.
My question is where webtest project look for this library?

If the webtests is missing a dependency:
Right click solution > manage nuget packages for solution > click manage on the package in question, then select your webtests project > ok.
If the webtests has a broken link to a dll :
Look at the references, and see if there are any yellow triangles, and where they point to. If that is the case, delete that reference and re-attach.

Related

Reference shared project in multiple solutions

I have a solution AddLog which has only one project AddLogClient of type shared project. I created it by right clicking on solution name->Add->Shared Project.
I want to use this shared project in other solutions. When I go to another solution MyApplication and want to add a reference to AddLogClient, I can't see it in the list of shared projects, because it is not located in the same solution. When I try to browse for it, it expects a file in .exe, .dll, .tlb, .olb, .olx or .winmd format. Adding .dll file (from bin folder from AddLogClient) would not be acceptable because every developer has different repository checkout location and we can't use relative paths.
How can I reference shared project from other solutions? Both solutions are under SVN.
The standard way of doing so, as #Sokopa suggested is through NuGet. For dev purposes, if you do not want to publish packages to Nuget servers, you can check the Generate Nuget Package on Build option and upon build it will create a nuget package in your build folder.
check this guide from microsoft docs

Developing and debugging projects in mutli-repository in Visual Studio

This is the basics of the problem I am having (of course it is oversimplified for the sake of the question):
I have 2 projects in a solution stored in mono-repository:
Project1 - outputs a library
Project2 - outputs an executable
When Project2 references Project1.
I would like to move to multi-repository where Project1 will be stored in different Repository from Project2.
Project1 will output a nuget package and Project2 will reference it instead the project itself.
The issue I am facing: in current situation (mono-repository) when during development I introduce a feature in
Project2 that also requires a change in Project1 it is not a problem. If there are problems I can discover it
during development time.
In a new way (multi-repository) I first need to make a change to Project1, create nuget and push it to nuget
store, then update reference in Project2. If I would have problems in Project1, I must go back to Project1,
fix the issue and push it again, update reference in Project2 and so on. Also, losing the benefit of debugging
both projects.
Is there a solution to this approach? To focus my question: if I have source codes of both projects on my dev machine,
is it possible somehow to instruct Visual Studio to use source code instead of referenced Nuget for debugging?
Hope I explained it right and clear as possible...
If you have two different projects and both of them are in different repositories, you could add the library as a submodule of the first project. I'm assuming you're using git. You could do this simply by:
git submodule add <link for the other repo>
In visual studio you just add the project to the same solution and then reference library from the executable. I'm not sure if that would do the trick for you, but I hope that works.
We have the exact same problem in our company.
This is 2 part problem.
First part is to have both repositories near each other... There are more options, we were deciding between these 2:
git submodule
meta repository (it is a compromise between mono-repository and multi-repository) you have 2 repositories you want to connect, so you create 3rd repository as a meta-repository via https://github.com/mateodelnorte/meta
Second part is how to connect those 2 repositories so that they are debuggable, but still apart each other... We though of these 3 ways:
new .sln in meta repository that will reference both projects (this didn't cut it, because we already been in a position when we had multiple .sln files and maintaining them is not that easy, because when you add some project into one, you have to add it to the other solutions and this goes sideways really quick)
using Reference and PackageReference with Condition - locally for debugging when .dll is build in ProjA then the ProjB would use "Reference", if not the ProjB would use PackageReference => this was our main solution to our problem until we did it like that... (Because we have more than 2 projects ProjA -> ProjB -> ProjC.. The problem here was when it was built locally, referenced via Reference DLL, then ProjA was not visible from ProjC, but when built via CI and referenced via PackageReference, then ProjA was visible from ProjC)
using only Nugets - Every build of ProjA it will create nuget locally (pre-release) and in ProjB, we would reference that via wild-cards. This works, until you make a second change into ProjA, because ProjB will cache that nuget in C:/Users//.nuget/packages :( so when building ProjA and packing the nuget we clear the newly built nuget from this packages folder. You have to restore ProjB every time you make change into ProjA, but this is where we landed as a final solution for now.
So the final solution for us is:
meta-repository for like 5 other repositories
for debugging we use locally built nugets with constant version of "major.minor.patch.65534-local"
for CI we use the same nuget packaging but we override the local version with
feature branches "major.minor.patch.build_number-branch_name" (having -something after the version makes that nuget pre-release)
master/main branch "major.minor.path.build_number"

Deploy project with xUnit reference as NuGet package

I have a library that contains some classes, which I need in several Unit Test projects. The library should be deployed as a NuGet package in my private repository. I already deployed some NuGet packages there, so I know what I have to do.
BUT: Inside of this library I need a reference to xUnit. And as soon as I add this reference, there is no more .nupkg file created when execute dotnet pack.
Another interesting effect is, that the project icon turns into a Unit Test icon as soon as I add xUnit:
Steps to reproduce:
Create a Class Library
Add a reference to the xUnit NuGet package
Right click the project and click on pack
Expected Behvior: there should be a .nupkg file in ./bin/Debug
Actual Behevior: there is no such file.
According to https://github.com/dotnet/cli/issues/7539, some projects seem to be "not packable" by default. You have to enable this manually by adding the following lines to your .csproj file:
<PropertyGroup>
<IsPackable>true</IsPackable>
</PropertyGroup>
After that, the .nupkg file is created expected.
Another option is to create Class Library project but don't add full xunit package, just:
xunit.abstractions and xunit.assert this way VS won't detect it as unit test project but you can still put some common code.

How to set dynamic path to nuget references?

Here is the sample project structure:
{ ProjectA }
{ packages } <-- packages are created here
{ ProjectA }
- ProjectA.csproj <-- references ProjectB and C.
- packages.config
- ProjectA.sln <-- contains all projects: A, B and C.
{ ProjectB }
- ProjectB.csproj
- packages.config
{ ProjectC }
- ProjectC.csproj
- packages.config
*{ packages} <-- *When I manually paste packages here. So one level above ProjectB.csproj file, then ProjectB compiles.
ProjectA solution has all three projects: A, B and C. ProjectA reference ProjectB and ProjectC.
When I compile ProjectA (projects B and C are compiled as well), all nuget packages are downloaded into {packages} folder on the same level as solution file. The problem is that ProjectB is not compiling. Yes... only ProejctB. I'm not even gonna investigate why only one project compiles although their configuration is exactly the same. Anyway...
In both ProjectB and C, when I expand References dlls from nuget are seen as they were missing (with the yellow rectangle). Somehow ProjectC compiles anyway, but ProjectB doesn't. The errors says it can't find the reference which is clearly in the packages folder.
My question is, how do I program/configure that sentance (psuedo code):
"Dear ProejctB, Please look for the references in the package folder generated on the same level as the solution file. The solution file, which is trying to compile you right now. Thank you"
PS. So technically, the path to the dll (reference) will be kinda dynamic. It will change depending on which solution file is opening/compiling the project. Is it possible?
The easiest way to fix it is by setting HintPath to:
<HintPath>$(SolutionDir)\packages\...
in .csproj files of ProjectB and ProjectC. It literally means: "look for the references in the package folder generated on the same level as the solution file. The solution file, which is trying to compile you right now"
This problem was reported multiple times. I believe it was fixed here. There is also NuGetReferenceHintPathRewrite, but I didn't test it.
Since packages.config is slowly becoming deprecated, you could migrate your projects from packages.config to ProjectReference, where the NuGet packages are specified inside the csproj file and a shared global location is used to store the packages (and there aren't any references with HintPath that would need changing).
In VS 2017 version 15.7, there will be an option to migrate in the context menu of the references node (already available in the preview):
PackageReference is already supported in VS 2017 since around 15.1 or 15.2, only the migration tool is in preview.
For new projects, VS 2017 (current version!) you can already select the default package reference style and allow for choosing it for new projects:
Nuget 3.x has packages.config concept and in this package name & version are mentioned at 2 place (In package.config and in .csproj file)
Reference in package config should be like this:
<package id="NewtonsoftJson" version="9.0.1" targetFramework="net46" />
Hint path in csproj should be like this:
<HintPath>..\packages\NewtonsoftJson.9.0.1\lib\net45\Newtonsoft.Json.dll</HintPath>
Here "..\packages" says go one level up(means at solution level) and look for "packages" folder.
You should verify that hint path is exists or not. and Package version should be same (9.0.1) in both the files(package.config and .csproj)
As your Porject C compiles successful, it seems some issue in the packages which is used by only ProjectB.
If you are still facing issue, please provide below detail for further analysis.
"package config"
"ProjectB.csproj"
msbuild compilation log, to know that in which package you
are facing issue.

The referenced component 'EntityFramework' could not be found.

So im downloading a project at home from work over team foundation server. I download the project and it won't compile because of the error. Warning 2 The referenced component 'EntityFramework' could not be found. Could anyone offer guidance in how I can get entity framework to work. I installed nuget package.
Thankyou
I suggest you to check:
1) "Allow NuGet to download missing packages during build" ticked
Tool --> Options... --> Package Manager --> General
2) "Project selected" ticked
Solution Explorer --> right-click on the solution/project --> Manage NuPackages
3) Rebuild Solution
EDIT
For completeness I would like to add that if you are working with a CI system (e.g. Jenkins) or you are using MSBuild on the command line, you need to select Enable NuGet Package Restore to make it work:
Enable NuGet Package Restore http://docs.nuget.org/docs/Workflows/images/enable-package-restore.png
I had the same problem. I solved it like this:
Choose References > Right-click > Add Reference ...
Choose Browse tab
Find your Project Folder > packages > EntityFramework.4.1.10331.0 > lib
Choose EntityFramework.dll
Click OK
This happened to me, after I moved projects to a subfolder.
Then, the relative paths to the packages folder were not correct anymore.
Got errors like that:
This project references NuGet package(s) that are missing on this computer. Use NuGet Package Restore to download them. For more information, see http://go.microsoft.com/fwlink/?LinkID=322105. The missing file is ..\packages\NETStandard.Library.2.0.1\build\netstandard2.0\NETStandard.Library.targets. PROJECTNAME D:\VSTS\TEAMPROJECT\src\PROJECTFOLDER\PROJECTNAME.csproj
Fixed it by editing the *.csproj file and corrected the relative paths, in my case from ..\packages to ..\..\packages
Also make sure to check the paths under
<Target Name="EnsureNuGetPackageBuildImports" BeforeTargets="PrepareForBuild">
There are good ways suggested by the developers, you may also try this solution to solve your problem.
In your case your project has a reference to the EntityFramework library, but library it self is not available to you project. You may try either the following:
If you have NuGet package manager:
Click on Project-> Manage NuGet Packages. It will open following window.
Find the EntityFramework and click Install.
- Alternatively, Download the EntityFramework library to your computer, then
Right-Click the Prject-> Add References...-> Browse-> Locate your
EntityFramework library-> Click OK
- Optionally you may use package manager to install library reference, check this link package-manager-console (Note: This might require NuGet Package manager)
I solved this issue by adding Entity Framework reference (Add ref) under C:\ Prog Files\Entity...\Binaries\Entity Framework.dll into my project. Hope this helps!
An old thread, but for anyone that this may help..
What worked for me was to go to the 'Packages' folder in the root of my solution and delete the EntityFramework.6.4.4 folder.
Then, go to Manage Nuget Packages menu option, and this banner pops up:
After pressing Restore the missing reference was restored.

Categories