I'm trying to compile the SvnQuery project (https://github.com/kalyptorisk/svnquery.git) with the a version SharpSVN.dll which I created on my PC, but I keep seeing the error message CS0400: The type or namespace name 'SharpSvn' could not be found in the global namespace (are you missing an assembly reference?).
Using the SharpSVN.dll which comes with the SvnQuery source code, I do not see this error message, nor any other.
Both SharpSVN.dll files look the same when I open them in .NET Reflector, but there is one difference - the file which I created doesn't have version information. (To be exact: When you look at the file's properties in File Explorer, "File version" and "Product version" are empty.)
I followed these steps to create SharpSVN.dll:
Check out from https://ctf.open.collab.net/svn/repos/sharpsvn (tried trunk and the 1.1200x branch). Open VisualStudio command prompt (tried 2012, 2015 and 2017), cd to 'imports' folder, run 'nant build'. Result: no errors, but this doesn't create SharpSVN.dll (and I guess it shouldn't).
Now double-click SharpSvn.sln in the src folder. This opens VS2017. Compile Release|x86. Result: no errors, many warnings, SharpSVN.dll (with no version information) created in src\SharpSvn\bin\Win32\Release.
Any ideas about this issue?
Thanks...
I found the solution. My problem has nothing to do with the missing version number. In fact, I had compiled SharpSVN for a .NET version higher than that of the SvnQuery project. After increasing the .NET version number for SvnQuery and related projects, all compiled well. And SvnIndex.exe seems to run smoothly (test still ongoing).
Related
I have installed pycparser that parses C code.
Using pycparser I want to parse an open source project, namely PostgreSQL(version-11.0). I have build it using Visual Studio Express 2017 compiler suite. However, during compilation it cannot find some header files, namely windows.h and winsock2.h.
While looking at the directory structure of the build PostgreSQL, I find that it does not have these header files. How to fix this issue?
Also a strange error occurred as:
postgresql/src/include/c.h:363:2: error: #error must have a working
64-bit integer datatype
Note: I am using Windows 10 64-bit platform and postgresql-11.0
The steps are as follows:
I downloaded visual studio 2017, Windows-10 SDK, Active Perl as described in the steps to build from source in PostgreSQL.
After this I open the developer command prompt of Visual Studio and navigate to the folder postgresql-11.0/src/tools/msvc
Use command "build" to build postgresql. The build process was successful, but still windows.h and winsock2.h was not found in directory structure of PostgreSQL.
I don't know pycparser, but your problem probably has two aspects to it:
You didn't give pycparser the correct list of include directories. The header files you mention are not part of PostgreSQL.
Maybe you can get the list from the environment of the Visual Studio prompt. I don't have a Windows here to verify that.
The error message means that neither HAVE_LONG_INT_64 nor HAVE_LONG_LONG_INT_64 are defined.
Now pg_config.h.win32, which is copied to pg_config.h during the MSVC install process, has the following:
#if (_MSC_VER > 1200)
#define HAVE_LONG_LONG_INT_64 1
#endif
Since you are not using MSVC, you probable don't have _MSC_VER set, which causes the error.
You could define _MSC_VER and see if you get to build then.
Essentially you are in a tight spot here, because pycparser is not a supported build procedure, so you'll have to dig into the source and fix things as you go. Without an understanding of the PostgreSQL source and the build process, you probably won't get far.
I'm struggling with building NLua from source on Windows.
It requires a modified Lua version, otherwise my code fails with a missing "lua52.dll".
https://github.com/NLua/NLua/issues/53
I tried to get it from here
https://github.com/NLua/lua
then used "cmake ." and built the resulting "lua.sln" in visual studio.
What happens is that I get a "lua52d.dll" (note the "d"). If I rename it, a "System.BadImageFormatException" is thrown by "KeraLua" (when I try with some "NLua.exe" executable I found in the "tests" folder of NLua).
Can anybody tell me how to build the modified lua52.dll required by NLua?
I already have a binary that works but need to be able to rebuild everything by myself. Possibly I'm simply using the wrong source tree.
You're using the right source tree, its just that you're compiling the debug version of the dll, not the release version of the dll. The added 'd' is to denote that it is the debug version of the dll, not the release version.
I'm to use nunit-console to run all of the tests in my solution.
I did this:
c:\some\path>nunit-console-x86.exe MySolution.sln
NUnit-Console version 2.6.2.12296
Copyright (C) 2002-2012 Charlie Poole.
Copyright (C) 2002-2004 James W. Newkirk, Michael C. Two, Alexei A. Vorontsov.
Copyright (C) 2000-2002 Philip Craig.
All Rights Reserved.
Runtime Environment -
OS Version: Microsoft Windows NT 6.1.7601 Service Pack 1
CLR Version: 2.0.50727.5466 ( Net 3.5 )
ProcessModel: Default DomainUsage: Default
Execution Runtime: net-3.5
Could not load file or assembly 'MyNamespace.Administration, Version=0.0.0.1, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified.
So, I decided to try nunit-x86.exe I did File > Open Project > MySolution.sln and got this:
---------------------------
NUnit
---------------------------
Test load failed!
System.IO.FileNotFoundException : Could not load file or assembly
'MyNamespace.Administration, Version=0.0.0.1, Culture=neutral,
PublicKeyToken=null' or one of its dependencies. The system cannot
find the file specified.
For further information, use the Exception Details menu item.
---------------------------
OK
---------------------------
The exception can be found here
What is happening and how do I fix it? (without having to maintain a MySolution.nunit file)
More information
MyNamespace.Administration is not even one of the dlls that contains tests, which means that nunit fails trying to load it to look for tests to run. Knowing this I edited the file created by nunit-x86.exe (MySolution.nunit) and removed all dlls that did not have tests. Sure enough, the tests work (in both gui and console). This is not acceptable for me because it would mean that I have to keep yet another configuration file. Nunit supporting .sln files was supposed to avoid this.
My tests run fine using TestDriven.Net (but I really need to run them using nunit-console)
I have looked at this answer but I cannot make sense of what the fusion log viewer says. Would posting that log help? Assembly binding Log Viewer, lists 3 files being created:
nunit-agent-x86.exe, this one seems to be trying to find MyNamespace.Administration.dll/EXE inside the nunit directories
Tests_24398275 x2 - one looking for nunit.core in my project folders and another looking for unit.core.interfaces inside my project folders. I would pay little attention to these two since they also appear in my manually edited .nunit project).
(per andreister comment) The problem seems to be with the project/assembly itself and not the creation method. If I create a .nunit project and try to add MyNamespace.Administration to it (using 'Add Assembly...' or 'Add VS project...') it fails.
Calling nunit-console-x86 somepath/bin/Debug/MyNamespace.Administration.dll directly works.
Reposting my reply on nunit-discuss:
The NUnit feature of loading VS solutions is really fairly limited and intended to work with simple projects or as a quick way to create an NUnit project file - i.e. load the solution and save as an NUnit project, then edit the xml file that is created. Since the solution file format doesn't indicate which files are tests, NUnit attempts to load each project to check if it contains any tests. (This is the same thing that Visual Studio 2012 and later does when using the test explorer window, btw.)
As you suggest, I think the particular assembly fails to load because of having a dependency that is one level up. When loading either a VS solution file or an NUnit project file, NUnit sets the application base to the directory containing the solution or project. That's why an NUnit project file one level up works.
The designers' intent in this sort of situation is that you would create an NUnit project file. I recognize that this is somewhat inconvenient, since it gives you another configuration file to maintain. I'm open to suggestions regarding the use of globs either on the command line or within the project file. Any such changes would probably go into the next major upgrade, NUnit 3.0.
Unfortunately, even after posting on nunit-discuss group I was unable to find a proper solution for this problem.
nunit-discuss group confirmed that my tests are failing because of having a dependency that is one level up.
I did however found an acceptable work-around.
Since calling the .dlls directly didn't have the same issues.
I could do this with globs, but I'm on windows... but I have git bash installed.
Taking advantage of my somewhat rigid project structure and naming convention I managed to do this:
"C:\Program Files (x86)\Git\bin\bash.exe" -c 'nunit-console-x86.exe //framework=net-4.5 //xml:nunitresults.xml MysolutionFolder/Tests/*/bin/Debug/*.Tests.dll'
Please note that I took advantage of my naming convention. This is very important to do in order to reduce the number of arguments.
When I did nunit-console-x86 MysolutionFolder/*/*/bin/Debug/*.dll instead of MysolutionFolder/Tests/*/bin/Debug/*.Tests.dll I got an error from nunit-console-x86 saying Bad file number.
Besides, it's faster if I just provide the right files.
If you have a more recent version of bash (4.0+, I think) you can instead use the following command (note the use of **):
"C:\Program Files (x86)\Git\bin\bash.exe" -c 'nunit-console-x86.exe //framework=net-4.5 //xml:nunitresults.xml MysolutionFolder/**/bin/Debug/*.Tests.dll'
Which is shorter and more permissive on the project structure.
I've got a project that uses Autofac, and the WebAPI integration
We run FxCop over our solution, and on opening autofac, I get the following:
The following indirectly-referenced assembly could not be found. This
assembly is not required for analysis, however, without it, analysis
results could be incomplete. This assemble was referenced by
Autofac.dll
System.Core, Version=2.0.5.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e, Retargetable=Yes
This causes the following error on our CI server:
FxCop return code (516): PROJECT_LOAD_ERROR ASSEMBLY_REFERENCES_ERROR
Is there a way to tell FxCop to ignore this?
Had the same issue with AutoMapper 3.1.0 on our project. The real problem is an old version of FxCop. The last official release was FxCop 10.0, but new versions of FxCop have been bundled with Visual Studio since 2012.
I just replaced the FxCop 10.0 with the version that can be found in:
C:\Program Files (x86)\Microsoft Visual Studio 11.0\Team Tools\Static Analysis Tools\FxCop
or
C:\Program Files (x86)\Microsoft Visual Studio 12.0\Team Tools\Static Analysis Tools\FxCop
and the problem was solved.
This is a common FxCop thing when running with Portable Class Libraries. It's not Autofac; you just happen to see it because Autofac is the only PCL you're using. In my experience, this error doesn't seem to happen if you're building on a Windows 8 machine, but on Windows 7 or Server 2008R2 I see this a lot.
It's not a bug, and no, you won't find 2.0.5.0 on your machine. That version is actually for Silverlight and runtime .NET "stuff" handles redirection to the right assembly version. Unfortunately, FxCop is less cooperative.
I see the same thing in my build and solved it using the suggestions from questions like this: How to fix FxCop error code 512?
You must add a reference to the assembly's directory in the FxCop project file. For instance:
<Targets>
<AssemblyReferenceDirectories>
<Directory>C:/Windows/Microsoft.NET/assembly/GAC_MSIL/Microsoft.Web.Infrastructure/v4.0_1.0.0.0__31bf3856ad364e35/</Directory>
<Directory>C:/Windows/Microsoft.NET/assembly/GAC_MSIL/System.Web.Mvc/v4.0_3.0.0.0__31bf3856ad364e35/</Directory>
</AssemblyReferenceDirectories>
Workaround for this issue is to copy the missing System.Core.dll to the project output directory. I made this as a postbuild event to copy System.Core.dll from a shared folder to project\bin directory.
You can get the copy of System.Core.dll from the Silverlight SDK 2 installation.
Now fxcop runs successfully without any issues. Note that I was using Fxcop integrator for Visual Studio 2010.
While building our project on the Build Server, the compilation fails with the error message:
TlbImp: error TI0000 : The input file 'C:\*.dll' is not a valid type library.
We tried to manually invoke the TlbImp command thru the VS2005 Command Prompt and the same error message appeared.
To investigate, we tried to create a clean build environment in a Virtual Machine (Vbox), then we run the build there. It went fine.
We also tried to invoke the same TlbImp command thru the VS2005 Command Prompt and it succeeded.
With that, we are assuming that there is nothing wrong with the DLL. Do you have any idea what scenario(s) can cause this problem?
EDIT:
Found the problem, see my answer. ;)
If it is working on one machine and not on the other, then most probably some dependency of this DLL is missing in your machine. Inspect the dll through DependencyWalker and you will get to know that which dependency hasn't been built properly.
After closer inspection, we found out that the environment variables on the official build server is FUBAR.
The official build server was installed with both VS2003 and VS2005. Our project is VS2005. The build script is using components from VS2003 instead of VS2005 because the VS2003 paths (Path, LIB, LIBPATH and INCLUDE) were first declared before the VS2005 paths.
A simple SET command to override the environment variables with the "correct ones" fixed the build!
Thanks!