I'm working on a program that uses a Dymo labelwriter 450, using a custom reference to interact with it from my c# program. I'm using DYMO.Label.Framework
When I sync with GitHub and Travis tries to test the software, it can't compile because it's missing a reference. error CS0246: The type or namespace name 'DYMO' could not be found. Are you missing an assembly reference?
I made sure to add the DLL to the project directory and reference it from the project using a relative path.
Is there something I need to add to the travis config? I can't find the package on NuGet.
Thanks.
Travis works fine with references, even nuget packages are actually referenced by relative path. Make sure your dll is pushed to github and saved to the right place. Project directory (not bin or something) should be the basis of relative path. One more thing to note -- path strings are case-sensitive as travis works on mono.
References like this worked for me:
<Reference Include="Nustache.Core">
<HintPath>..\..\Tools\Rosalia\Nustache.Core.dll</HintPath>
</Reference>
Related
I'm converting a (working) .netstandard library project into a multi-targetted project that will target:
<targetframeworks>netstandard2.1;xamarinios10;monoandroid10.0;monoandroid12.0;</targetframeworks>
I'm having issues with the System.ComponentModel.DataAnnotations reference. Sepcifically I get this error (for eveything except the .netstandard target):
The type 'DataType' is defined in an assembly that is not referenced. You must add a reference to assembly 'System.ComponentModel.DataAnnotations, Version=2.0.5.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'.
After a bit of searching I tried adding the System.ComponentModel.Annotations (4.7.0) nuget package. This gave the same error.
In the nuget directory for this I noticed that where the .dll would normally live it had a file '.' - I didn't know if that was important (.nuget\packages\system.componentmodel.annotations\4.7.0\ref\MonoAndroid10) - the .netstandard dll was there as expected.
I've also noticed that (a separate) Xamarin.Android project seems to use the System.ComponentModel.DataAnnotations.dll which lives in C:\Program Files\Microsoft Visual Studio\2022\Enterprise\Common7\IDE\ReferenceAssemblies\Microsoft\Framework\Xamarin.iOS\v1.0
I'm not sure if the right version of Mono.Android (or ios equivalant) is being targetted or I have to specify a specific assembly version, or whether I'm down the wrong track completely?
Thanks in advance,
Paul.
As the comment above mentions, to workaround this issue, I moved the bit of offending code (that used the System.ComponentModel.DataAnnotations) into a seperate project that targetted .netstandard2.1 and then referenced this project from my multi-targetted project.
I'm working on converting a large WPF solution's projects to SDK style and ran into some issues.
The solution is large with multiple projects(old style) all targeting .net452 and some nugets(some made by me) installed, targeting both .net452 and .netstandard2.1
This all seems to work fine, somehow the nuget manages to install the correct version targeting .net452.
I have decided to slowly convert the projects inside the solution to SDK style targeting .net452 and .netstandard2.1 just like the nugets.
This is where the problem starts, one project was converted so far that is referenced by multiple other projects.
Localy everything seems to build and run fine, however when Azure DevOps(VS version 2019) is used to build the solution there are 2 scenarios:
The famous error message is shown:
"Error CS0012: The type 'Object' is defined in an assembly that is not referenced. You must add a reference to assembly 'netstandard, Version=2.1.0.0"
It builds fine but on app launch it crashes with:
"Could not load file or assembly 'netstandard, Version=2.1.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' or one of its dependencies. The system cannot find the file specified."
I'm suspecting that the problem is related to referencing the SDK project, it looks like that somehow it references the .netstandard2.1 instead of the .net452.
The reason this is my suspicion is that if targetframework is set to only .net452 on the referenced project everything works fine.
Google has led me to two possible solutions to tell the project what framework to use from the reference:
<ProjectReference Include="..\..\..\..\foo\foo.csproj"
AdditionalProperties="TargetFramework=net452">
<Project>{xxxxxx-xxxxxx-xxxxx-xxxxx-xxxxxxx}</Project>
<Name>foo</Name>
</ProjectReference>
and
<ProjectReference Include="..\..\..\..\foo\foo.csproj">
<SetTargetFramework>TargetFramework=net452</SetTargetFramework>
<Project>{xxxxxx-xxxxxx-xxxxx-xxxxx-xxxxxxx}</Project>
<<Name>foo</Name>
</ProjectReference>
This doesn't look like it's doing anything and the problem still persists.
At the moment I ran out of ideas and I'm here asking for help. Please let me know what I'm doing wrong or what else I can try.
I have found the problem. The issue was that I had set an output directory in AzureDevOps. When the builds for the projects were finished everything was copied there, first the .net4.5.2 target DLLs and then overwritten with the netstandard2.1 dlls. To avoid this issue in case it happens to anyone, let the compiler put the files into the root project by default and copy them afterwards wherever you want.
I have created a C# test project in VS2015 RC. it builds locally but when i attempt to build on our CI build server (TeamCity) it fails with errors:
UnitTest1.cs(2,17): error CS0234: The type or namespace name
'VisualStudio' does not exist in the namespace 'Microsoft' (are you
missing an assembly reference?)
[... .Tests.csproj]
UnitTest1.cs(9,10): error CS0246: The type or namespace name
'TestMethod' could not be found (are you missing a using directive or
an assembly reference?)
[... .Tests.csproj]
Clearly this is because the assembly containing these namespaces (Microsoft.VisualStudio.QualityTools.UnitTestFramework) is not on the build server; on my local machine it resides at C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\PublicAssemblies\Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll.
I could copy the assembly into my solution so that it becomes part of the codebase but manually moving files feels like a bit of an inelegant hack. I searched around on nuget and found http://www.nuget.org/packages/Microsoft.VisualStudio.QualityTools.UnitTestFramework/ which I figured would do the trick, but installing that package failed with:
Install-Package : Could not install package
'Microsoft.VisualStudio.QualityTools.UnitTestFramework 11.0.50727.1'.
You are trying to install this package into a project that targets
'.NETFramework, Version=v4.5.2', but the package does not contain any
assembly references or content files that are compatible with that
framework
What's my best option of solving this? I'm surprised that creating a test project in VS2015 does not automatically include all the dependencies that I need, though perhaps I'm being naive (I'm something of a fledgling dot netter).
The answer is similar to option 1 in eng.augusto's answer.
Microsoft doesn't provide NuGet for the latest version of Microsoft.VisualStudio.QualityTools.UnitTestFramework,
but rather supplies it as a part of Visual Studio
(normally at C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\PublicAssemblies\Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll)
I created the folder Microsoft.VisualStudio.QualityTools as a subfolder of my solution and copied:
Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll
Microsoft.VisualStudio.QualityTools.UnitTestFramework.xml
The files should be added to source control (even if DLLs are usually ignored).
Then I changed references in my Test.csproj to refer to a new location.
Hmm I have some ideas, so choose the one that best fits your needs
A simple answer should be mark the DLL to copy local and use a folder like Assemblies in the same folder of the solution and references "Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll"
Install Visual Studio in your build server. Sounds nuts but it's the closest to "developer machine" that you have.
Install the DLL in the GAC so you don't have to bother with this.
Fix the NuGet package (Adding a reference for the .NET Framework version) and use it.
Downgrade your .NET Framework version so you can use the NuGet package.
Create your own NuGet server! (and add the reference of the DLLs you need).
IMHO I'd choose the first answer, because it seems to be the "best way" to use NuGet to resolve all your packages problems but you are using a DLL that you don't know if it should be trusted.
In system used in "old" languages like C, or C++ it's common you download the source code and the libraries needed for the code to run so I do not think the NuGet package it's the best solution.
Using the first option you always have the same version and could check the MD5 of the file and know exactly what is running in your build server.
Maybe the real best option should be 6. When you use your own NuGet server to handle your DLLs making your live more awesome and trustable.
For projects created in VS 2017. Adding Nuget package Microsoft.VisualStudio.QualityTools.UnitTestFramework.Updated allows to build unit test projects on CI without VS installed on build server:
I was having this issue when trying to use MSBuild on our dev server via our CI/CD process after I was asked to uninstall VS2013 from our dev server by our IT team.
In my case in my build output there were a few lines with the word Considered. What this means is that the build is considering those folders for locations where the file may be located. One of those lines was as follows:
Considered "C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5\Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll", but it didn't exist.
I copied Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll from my local machine to that folder on the dev server and the error went away.
Of course Microsoft does a s...t job. To fix this, you need to copy the dll's to some convinint lication and reference them from your ptoject .csproj file.
<HintPath>..\packages\Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll</HintPath>
</Reference>
</ItemGroup>
<ItemGroup>
<Reference Include="QualityTools-Fakes">
<HintPath>..\packages\Microsoft.QualityTools.Testing.Fakes.dll</HintPath>
</Reference>
</ItemGroup>
<ItemGroup>
I don't understand why when we add this from VSudio it does not update the same file instead no one has an idea what it does. In Java you have a single file pom.xml or build.gradle, nothing else. In C# there is all sorts of stuff which adds no value but confusion.
TFS (2012) Build is checking C:\Windows\Microsoft.NET... for a few of my project references even though the dlls are included as project references (set to copy local) in a folder I'm checking in.
Building outside of TFS, both in VS and using MSBuild.exe command line succeeds.
I can see in the errors and warnings that the references it is complaining about not being to find 'Could not resolve this reference. Could not locate...' are all due to it simply not checking in the checkin dependency folder as defined in the proj file.
Any ideas on how to correct this?
I believe there is a "check gac first" rule for DotNet dependency resolution.
So I do my references like this.
\MySolution.sln
\BALLayer\Biz.csproj
\DALLayer\Data.csproj
\PresLayer\MyWebsite.csproj
\ThirdPartyReferences\
\ThirdPartyReferences\SuperCoolDll111.dll
\ThirdPartyReferences\SuperCoolDll222.dll
\ThirdPartyReferences\SuperCoolDll333.dll
This way, all csprojects reference the needed dll(s) with a relative path.
All cs projects reference the SAME dll.
This has helped me avoid the "I'm gonna look in the GAC no matter what you want me to do" issue.
Nuget does this similarly.
\packages\
\packages\repositories.config
\packages\SomeLibrary\SomeDll.dll
\packages\SomeLibrary\MyNugetDll.dll
and cs projects reference the same .dll with a relative path.
............
Footnote:
Open up your .csproj file(s) in notepad, and look for the HintPath.
Mine always say something like
<Reference Include="MyNugetDll.dll>
<SpecificVersion>False</SpecificVersion>
<HintPath>..\packages\SomeLibrary\MyNugetDll.dll</HintPath>
</Reference>
OR
<Reference Include="SuperCoolDll333.dll>
<SpecificVersion>False</SpecificVersion>
<HintPath>..\ThirdPartyReferences\SuperCoolDll333.dll</HintPath>
</Reference>
.........
But I think the crux of your issue is "copy local" and the "gac first" rule.
.........
PS
Here is another question that discusses the order...better than I could.
In what order are locations searched to load referenced DLLs?
EDIT::::
So lessons learned:
If you have your third party references checked into source control, and the build machine says "i cannot find xyz.dll", then make sure that dll is actually in source control. There are alot of "voodoo" paths on (the local development) machine with visual studio installed, and subsequently will NOT be on the "build machine".
If you use nuget and you check in your dlls, make sure they are all checked in. You might add a new entry to the packages.config and then forget to put the actual dll(s) into source control.
There are some ways to use nuget that you only put the packages.config in source control, and not the third party dlls. Check the comments of this post for articles about that.
I have tried all the suggestions below but still no joy.
I'm now trying a console application, and let me explain exactly what I'm doing.
I create a new console project in VS 2010
I add a number of references (dll's) some that aren't mine such as Castle.Winsor and N2 CMS dlls
in the console app I can add using statements indicating I am using name spaces within the referenced DLLs
I start writing code.
As soon as I compile all the code that uses the referenced DLLs immediately complains with "The type or namespace name '' could not be found (are you missing a using directive or an assembly reference?)"
I have tried setting the dlls to copy to local always, I have copied the DLL into the same directory, I have tried added reference by project and adding a reference to the DLL's themselves
I don't get this problem with a web application project or a ASP.net project they always work fine, only something that is compiled to an EXE like a console app or windows service.
there must be something I'm missing or I would have got this working by now.
Change the project Target to a non Client Profile target. Right click the Project and select Properties, you should see a list of Framework versions. As you are using VS2010, the Console project you've created by default targets .NET Framework 4.0 Client Profile, change that to .NET Framework 4.0.
Check if Copy Local is set to true for the referenced assembly.
First, as to your question, its hard to know exactly what you're doing wrong, but from the fact that you're using an underscore in an assembly name (and probably in namespaces and type names), it suggests you're rather new to the .NET world.
This suggests that you're adding references to other projects in your solution by browsing to the compiled assembly, rather than by adding a Project Reference. When adding a reference, you must select the Project tab rather than browsing for the assembly.
Even if you don't believe this is the issue, remove all references and re-add project references to make absolutely sure. Assumption, asses etc.
Once you've done that, I'd strongly suggest remove all the underscores from your types, namespaces and assemblies. You might want to go read the framework design guidelines, too.
Open your .Proj(Windows service project file) file in notepad and check whether your assembly location(data_object) is the same which you are pointing.
When you open .Proj file in notepad you can check for,
Project reference,
<ProjectReference Include="C:\StackOverflow\StackOverflow.csproj">
And if you giving dll or exe refrence then
<Reference Include="StackOverflow, Version=1.0.0.0, Culture=neutral, processorArchitecture=x86">
<SpecificVersion>False</SpecificVersion>
<ExecutableExtension>.exe</ExecutableExtension>
<HintPath>C:\StackOverflow\bin\Debug\StackOverflow.exe</HintPath>
</Reference>
I suggest you to give exact location including drive name like above example.
Other option you may try,
1. Clean and rebuild
2. Add Project reference if you already tried dll reference
3. Check whether the folder (referred assembly location) is Read Only then remove it.
In VS 2019, I had two projects, one C++ and other one C# Console in one solution file. When tried to add a dll reference through "Add reference", I was not able to see Browse button in "Reference Manager" window, to select dll file.
But when I created only C# Console app inside solution then I could add dll reference.