Ik krijg deze fout, maar ik weet niet hoe ik het moet repareren.
Ik gebruik VISUAL STUDIO 2013. Ik heb de oplossingsnaam myprojecttest gemaakt
Dit is de structuur van mijn testoplossing:
– FUNCTION.H
#ifndef MY_FUNCTION_H
#define MY_FUNCTION_H
int multiple(int x, int y);
#endif
-Function.CPP
#include "function.h"
int multiple(int x, int y){
return x*y;
}
– MAIN.CPP
#include <iostream>
#include <cstdlib>
#include "function.h"
using namespace std;
int main(){
int a, b;
cin >> a >> b;
cout << multiple(a, b) << endl;
system("pause");
return 0;
}
Ik ben een beginner; Dit is een eenvoudig programma en het loopt zonder fout.
Ik lees op het internet en raakte geïnteresseerd in de eenheidstest, dus ik heb een testproject gemaakt:
MENU Bestand → NIEUW → Project … → Geïnstalleerd → Sjablonen → Visual C++ → Test → Native Unit Test Project →
Naam: Unittest1
Oplossing: Toevoegen aan oplossing
Dan de locatie automatisch overgeschakeld naar het pad van de huidige open oplossing.
Dit is de mapstructuur van de oplossing:
Ik bewerkte alleen bestand Unittest1.cpp :
#include "stdafx.h"
#include "CppUnitTest.h"
#include "../MyProjectTest/function.h"
using namespace Microsoft::VisualStudio::CppUnitTestFramework;
namespace UnitTest1
{
TEST_CLASS(UnitTest1)
{
public:
TEST_METHOD(TestEqual)
{
Assert::AreEqual(multiple(2, 3), 6);
// TODO: Your test code here
}
};
}
Maar ik krijg:
FOUT LNK2019: onopgelost extern symbool.
Ik weet dat de implementatie van functie meerdere ontbreekt.
Ik heb geprobeerd het -functie.cppp -bestand te verwijderen en ik heb de aangifte vervangen door de definitie en het liep. Maar het schrijven van zowel de verklaring als de definitie in hetzelfde bestand wordt niet aanbevolen.
Hoe kan ik deze fout oplossen zonder dat te doen? Moet ik het vervangen door #include "../MyProjectTest/function.cpp"in bestand unittest.cpp?
Antwoord 1, Autoriteit 100%
Eén optie zou zijn om function.cppin uw UnitTest1Project toe te voegen, maar dat is mogelijk niet de meest ideale oplossingstructuur. Het korte antwoord op uw probleem is dat bij het bouwen van uw UnitTest1Project, de compiler en de linker geen idee hebben dat function.cppbestaat en ook niets hebben om een link te hebben definitie van multiple. Een manier om dit te verhelpen, maakt gebruik van het koppelen van bibliotheken.
Aangezien je unit-tests zich in een ander project bevinden, neem ik aan dat het je bedoeling is om van dat project een op zichzelf staand unit-testing-programma te maken. Met de functies die u aan het testen bent in een ander project, is het mogelijk om dat project op te bouwen naar een dynamisch of statisch gekoppelde bibliotheek. Statische bibliotheken zijn tijdens het bouwen gekoppeld aan andere programma’s en hebben de extensie .lib, en dynamische bibliotheken worden tijdens runtime gekoppeld en hebben de extensie .dll. Voor mijn antwoord geef ik de voorkeur aan statische bibliotheken.
U kunt van uw eerste programma een statische bibliotheek maken door deze in de projecteigenschappen te wijzigen. Er zou een optie moeten zijn onder het tabblad Algemeen waar het project is ingesteld om te bouwen naar een uitvoerbaar bestand (.exe). U kunt dit wijzigen in .lib. Het bestand .libwordt op dezelfde plaats gebouwd als het bestand .exe.
In uw UnitTest1-project kunt u naar de eigenschappen gaan en onder het tabblad Linker in de categorie Extra bibliotheekmappen het pad toevoegen waarnaar MyProjectTestwordt gebouwd. Voeg vervolgens voor Aanvullende afhankelijkheden onder het tabblad Linker – Invoer de naam van uw statische bibliotheek toe, hoogstwaarschijnlijk MyProjectTest.lib.
Dat zou je project in staat moeten stellen om te bouwen. Houd er rekening mee dat door dit te doen, MyProjectTestgeen op zichzelf staand uitvoerbaar programma zal zijn, tenzij u de build-eigenschappen indien nodig wijzigt, wat minder dan ideaal zou zijn.
Antwoord 2, autoriteit 47%
Klik in de Visual Studio-oplossingsstructuur met de rechtermuisknop op het project ‘UnitTest1’ en vervolgens Toevoegen→ Bestaand item→ kies het bestand ../MyProjectTest /function.cpp.
Antwoord 3, autoriteit 22%
Omdat ik wil dat mijn project wordt gecompileerd naar een op zichzelf staand EXE-bestand, heb ik het UnitTest-project gekoppeld aan het bestand function.objdat is gegenereerd vanuit function.cppen het werkt.
Klik met de rechtermuisknop op het ‘UnitTest1’-project → Configuratie-eigenschappen→ Linker→ Invoer→ Extra afhankelijkheden→ voeg “..\MyProjectTest\Debug\function.obj” toe.
Antwoord 4, autoriteit 12%
Ik kwam dit probleem net tegen in Visual Studio 2013. Blijkbaar is het nu niet genoeg om twee projecten in dezelfde oplossing te hebben en de afhankelijkheden in te stellen. U moet er een projectreferentie tussen toevoegen. Om dat te doen:
- Klik met de rechtermuisknop op het project in de oplossing verkennen
- Klik op Toevoegen => Referenties…
- Klik op de knop Nieuwe referentie toevoegen
- Vink de vakjes aan voor de projecten waarop dit project steunt
- Klik op OK
Antwoord 5, autoriteit 9%
Het bleek dat ik .c-bestanden gebruikte met .cpp-bestanden. Het hernoemen van .c naar .cpp loste mijn probleem op.
Antwoord 6, autoriteit 8%
Een andere manier waarop je deze linkerfout kunt krijgen (zoals ik was) is als je een instantievan een klasse exporteert uit een DLL-bestand, maar die klasse zelf niet als import/export hebt gedeclareerd.
#ifdef MYDLL_EXPORTS
#define DLLEXPORT __declspec(dllexport)
#else
#define DLLEXPORT __declspec(dllimport)
#endif
class DLLEXPORT Book // <--- This class must also be declared as export/import
{
public:
Book();
~Book();
int WordCount();
};
DLLEXPORT extern Book book; // <-- This is what I really wanted, to export book object
Dus hoewel ik in de eerste plaats slechts een exemplaarvan de klasse Book met de naam Bookhierboven exporteerde, moest ik de klasse Bookdeclareren als export/import class ook, anders veroorzaakte het aanroepen van book.WordCount()in het andere DLL-bestand een linkfout.
Antwoord 7, autoriteit 3%
Controleer de tekenset van beide projecten in Configuratie-eigenschappen→ Algemeen→ Tekenset.
Mijn UnitTest-project gebruikte de standaardtekenset Multi-Byteterwijl mijn bibliotheken in Unicodewaren.
Mijn functie gebruikte een TCHARals parameter.
Als resultaat werd in mijn bibliotheek mijn TCHARgetransformeerdin een WCHAR, maar het was een char* in mijn UnitTest: het symbool was anders omdat de parameters uiteindelijk niet hetzelfde waren.
Antwoord 8, autoriteit 2%
Ik heb net ontdekt dat LNK2019optreedt tijdens compilatie in Visual Studio 2015 als ik vergeet een definitie op te geven voor een gedeclareerde functie binnen een klasse.
De linkerfout was zeer cryptisch, maar ik beperkte het tot wat er ontbrak door de fout door te lezen en gaf de definitie buiten de klas om dit op te helderen.
Antwoord 9
Als u in Visual Studio 2017 openbare leden wilt testen, plaatst u eenvoudig uw echte project en testproject in dezelfde oplossing en voegt u een verwijzing naar uw echte project toe aan het testproject.
Zie C++ Unit Testing in Visual Studiovan de MSDN-blog voor meer details. U kunt ook Write unit tests voor C/C++ in Visual Studioevenals Gebruik het Microsoft Unit Testing Framework voor C++ in Visual Studio, de laatste is als u niet-openbare leden moet testen en de tests in hetzelfde project moet plaatsen als uw echte code .
Houd er rekening mee dat dingen die u wilt testen, moeten worden geëxporteerd met __declspec(dllexport). Zie Exporteren vanuit een DLL met __declspec(dllexport)voor meer details.
Antwoord 10
In mijn geval, stel het cpp-bestand in op “C/C++ compiler” in “property”->”algemeen”, los de LNK2019-fout op.
Antwoord 11
Voor mij werkt het als ik deze regel hieronder toevoeg in .vcxprojin het itemGroupcpp-bestand, dat is gekoppeld aan het header-bestand.
<ClCompile Include="file.cpp" />
Antwoord 12
In het begin van uw headerbestand function.h include
#ifdef __cplusplus
extern "C" {
#endif
Zoals dit:
#ifndef MY_FUNCTION_H
#define MY_FUNCTION_H
#ifdef __cplusplus
extern "C" {
#endif
int multiple(int x, int y);
#ifdef __cplusplus
}
#endif
#endif
Hiermee wordt de CPP-compiler op uw eenheidstestproject verteld om dit te compileren .h-bestand als C-bestand, het genereren van de objecten met de verwachte symboolnamen