I recently published a library targeted to build for .Net4.5. Now that Windows 8 is out, I'd like to essentially build for that platform too.
Unfortunately, some of the code I used in the original library hasn't made it into the RT core, however I've spent most of today doing the adjustments and testing with a copy of the code.
Essentially I've now got two code files, an original, and a copy with about 5 lines updated and using a different namespace. I've done conditional compilation for Debug/Release, however I've never done a batch compile.
My ideal goal would be to combine these files, perhaps using compiler flags and #if, to make the code more manageable. Then compile to Library.WinRT.dll and Library.x86.dll. I don't mind having 2 different projects, symbolically linking the files, but I really don't want duplicate code.
Any suggestions on how I can go about doing this? Anyone got experiences they'd like to share?
I think you answered your own question. Use compiler flags, link to files between projects (not using the file system's symbolic links, but rather add existing files from one project to the other as link - using the drop down next to the "Add" button in the open file dialog). What do you mean by batch compile? Do you want to build from command line? Then you can do something like this:
msbuild /verbosity:quiet /fl /t:Rebuild /p:Configuration=Release Library.WinRT\Library.WinRT.csproj
msbuild /verbosity:quiet /fl /t:Rebuild /p:Configuration=Release Library.NET45\Library.NET45.csproj
Related
I've downloaded Apache Thrift and have created a thrift file that nicely generates code (I'm using csharp). I've now got to the stage of including Thrift in my Visual Studio project (I'm using 2013 version) and am stuck on how to do this.
Thrift includes all the source files I need but just copying them to Visual Studio creates a load of errors. I noticed that there are several makefiles that come with the source: There's a Makefile.am and a Makefile.in. I tried running:
nmake -f Makefile.am
nmake -f Makefile.in
but i keep getting syntax errors.
Any help would be much appreciated.
Here are the syntax errors:
Makefile.am(73) : fatal error U1034: syntax error : separator missing
Stop.
and:
Makefile.in(16) : fatal error U1035: syntax error : expected ':' or '=' separator
Stop.
As you can see the errors are just basic syntax one's.
Still a good idea to post the source and the error messages. We don't like guesswork, because it is highly inefficient. And you want quick help, don't you?
The help I need is what to do with all the different types of makefiles.
First, I'm not sure why you need a makefile at all. You could easily achieve he same result by calling Thrift in the prebuild step. I do that via batch files, which gives me enough control over the process. But, yes, you could of course also call nmake -f makefile here, but note there is no extension after makefile.
In a nutshell and without spending too much time on details, the makefile.am and makefile.in are typically GNU automake files. Roughly, during bootstrap.sh && configure these makefile.am files are converted into makefile.in files and finally into makefile files, which then are to be consumed by make or equivalent tools.
But honestly, on Windows platforms, GNU automake is something that I would consider the option of last resort - if there is any other option available, choose that one.
Last not least, the tutorial, library and test *.csproj files show at least one way how to integrate Thrift in the prebuild step.
I started to use gdal_csharp dll in my application and read a geotiff file. but it says:
The type initializer for 'OSGeo.GDAL.GdalPINVOKE' threw an exception.
it's my code
string fileName = #"/path to geotiff file";
OSGeo.GDAL.Dataset DS =
OSGeo.GDAL.Gdal.Open(fileName, OSGeo.GDAL.Access.GA_ReadOnly);
can anyone help?
Edit:
I have these dlls
This is the full error message:
It says that cannot load gdal_wrap. But when I'm going to add that dll to my application the below message is shown:
As an update to this there is now GDAL maintained by the SharpMap team as a nuget package here which is updated regularly. You'll need to install both the "GDAL.Native" and "GDAL" package for your project to use the GDAL library. Once installed via nuget, they'll automatically create a "GdalConfiguration.cs" that you call into to initialize the GDAL paths before starting. The only thing to note is the packages are setup to automatically copy their appropriate GDAL libraries to your output build directory. If you need to deploy the application you'll have to do a bit of extra effort.
To solve this one I downloaded the prebuilt libraries as described here and grabbed FWTools from here.
The unmanaged DLLs I used came from \install_dir\FWTools2.4.7\bin and the C# wrapper from \install_dir\FWTools2.4.7\csharp.
gdal14.dll, msvcp71.dll and msvcr71.dll came from here, which is mentioned in that first link.
The error you are receiving re gdal_wrap.dll is referring to one of its dependencies. I threw that DLL into depends and it found a lengthy list of dependent libraries. Note that this list is likely longer due to my use of the FWTools distribution - if you built your version from source it may look different, though the same principles apply.
To get the above code to work on my machine I had the following files in my output directory:
gdal14.dll
gdalconst_csharp.dll
gdalconst_wrap.dll
gdal_csharp.dll
gdal_fw.dll
gdal_wrap.dll
geos_fw.dll
geotiff_fw.dll
hdf5dll.dll
hdf_fw.dll
jpeg12_osgeo.dll
jpeg_osgeo.dll
libcurl.dll
libeay32.dll
libexpat.dll
libmysql.dll
libpq.dll
libtiff_fw.dll
lti_dsdk_dll.dll
mfhdf_fw.dll
msvcp71.dll
msvcr71.dll
NCScnet_fw.dll
NCSEcw_fw.dll
NCSUtil_fw.dll
netcdf.dll
ogdi_32b1.dll
proj.dll
sqlite3.dll
ssleay32.dll
szlibdll.dll
xerces-c_2_7.dll
zlib1.dll
zlib_osgeo.dll
Now these don't necessarily all have to live in the output directory - as long as they are on your path somewhere (e.g., \Windows\System32) you should be fine.
I know it's an old question, but I believe my answer might help someone.
I was able to successfully compile and run examples using c# gdal by doing the following:
Downloading GDAL sdk from http://www.gisinternals.com/ (64 bit in my case)
Executing the SDKShell.bat script to set the system environment paths, etc.
Creating a project in Visual Studio. And referencing all .net dlls (the ones that names end with _csharp.dll), located in \bin\gdal\csharp\ inside downloaded SDK
Setting platform target in Visual Studio project settings to x64 to get rid og bad image format exceptions. The last step wouldn't be necessary if I'd choosse 32bit version of SDK to work with.
I did not install fwtools at all. It seems like the last build of fw_tools is relatively old, and sdk is still maintained.
I know this is a reasonably old question now, but I found this in google after researching the same problem myself, so this means that for searches on this error this is still a very relevant page to update given it's still in the top 5 from the big G when the same problem is searched.
In my case it was the answers from "DeusExMachina25" and "Grzegorz Sławecki" that struck a chord.
I'm writing some software that makes use of the current builds of "sharp map" on NUGet (as of 24th of June 2016) and my software kept throwing the same gdal_wrap message as the OP originally reported, even though I'm using the GDAL package provided by the Sharpmap team.
I didn't realize that the NUGet installer for the package had installed a configuration class for me, but after reading through this thread and finding out that it does I went looking for it.
Sure enough I found the file 'GdalConfiguration.cs' in my project and added a call to it in an appropriate place in my project, expecting GDAL to be initialized correctly.
However, after I did this, I still had the same problem.
So, I set a break point on the beginning of the GDAL routine that had been added, and waited until the break point was hit.
I then traced through the method, and eventually found the following line:
var gdalPath = Path.Combine(executingDirectory, "gdal");
at around line 64 in the file.
Tracing through this, I noticed that the path being built was:
d:\geodata\maptest\maptest\bin\debug\gdal
but the NUGet installer had installed all the dependent assemblies in
d:\geodata\maptest\maptest\bin\debug
Exactly where I expected them to be.
I changed line 64 so that it now read:
var gdalPath = Path.Combine(executingDirectory, "");
and voila, the error went away and everything started to work.
I could have done things the other way too, and created a folder called gdal, then copied everything into that, but that then would have gotten deleted when I did a "clean" on the project.
Since the config class, set's up various environment variables based on this path, quickly changing that one line also fixes up the path for the GDAL data files , plugins and a few other things too.
You could try using Dependency Walker to see if there are any dlls that gdal_csharp is trying to grab but cannot.
Have you added the path to your GDAL libraries to your PATH environment variable? I downloaded my files from http://vbkto.dyndns.org/sdk/?_sm_au_=iVVqjsHS2n46WP00 and here's my path: C:\libs\release-1600-gdal-1-9-mapserver-6-2\bin.
To use the C#-bindings of GDAL you need an installation of FWTools (from http://fwtools.maptools.org/) as well as the most current binaries that match your system (from http://vbkto.dyndns.org/sdk/). Afterwards it is important to include the bin-directory of FWTools (example for 64bit-systems: C:\Program Files (x86)\FWTools2.4.7\bin) in your PATH variable as well as the necessary dlls (gdal_csharp.dll was mentioned in the question) in your Visual Studio project references. I outlined the complete processs here.
This process works on 32 bit as well as 64 bit systems, I tested it with VS 2010 and 2012.
Remove the path to python from the system variables. Because the main gdal paths conflict with python 27
Did you forget to:
GdalConfiguration.ConfigureGdal();
GdalConfiguration.ConfigureOgr();
Gdal.AllRegister();
Ogr.RegisterAll();
In my case the issue was:
I had 2 projects in my solution: ProjectA and ProjectB
I was executing ProjectA, and ProjectA was referencing ProjectB
ProjectB is the one that contained the references to both GDAL and GDAL.Native
ProjectA tried to find GDAL.Native's files under ProjectA\bin\Debug\netcoreapp3.1\gdal ... but in reality those files are under ProjectB\bin\Debug\netcoreapp3.1\gdal
Possible solutions:
Dirty solution: just copy the files from ProjectB under ProjectA\bin\Debug\netcoreapp3.1
Okayish solution: add the GDAL.Native package to each one of your "entry projects"
I don't like either of those solutions. This stuff happens under GdalConfiguration.cs, so maybe there is a way to modify it to find the correct path.
I started to use gdal_csharp dll in my application and read a geotiff file. but it says:
The type initializer for 'OSGeo.GDAL.GdalPINVOKE' threw an exception.
it's my code
string fileName = #"/path to geotiff file";
OSGeo.GDAL.Dataset DS =
OSGeo.GDAL.Gdal.Open(fileName, OSGeo.GDAL.Access.GA_ReadOnly);
can anyone help?
Edit:
I have these dlls
This is the full error message:
It says that cannot load gdal_wrap. But when I'm going to add that dll to my application the below message is shown:
As an update to this there is now GDAL maintained by the SharpMap team as a nuget package here which is updated regularly. You'll need to install both the "GDAL.Native" and "GDAL" package for your project to use the GDAL library. Once installed via nuget, they'll automatically create a "GdalConfiguration.cs" that you call into to initialize the GDAL paths before starting. The only thing to note is the packages are setup to automatically copy their appropriate GDAL libraries to your output build directory. If you need to deploy the application you'll have to do a bit of extra effort.
To solve this one I downloaded the prebuilt libraries as described here and grabbed FWTools from here.
The unmanaged DLLs I used came from \install_dir\FWTools2.4.7\bin and the C# wrapper from \install_dir\FWTools2.4.7\csharp.
gdal14.dll, msvcp71.dll and msvcr71.dll came from here, which is mentioned in that first link.
The error you are receiving re gdal_wrap.dll is referring to one of its dependencies. I threw that DLL into depends and it found a lengthy list of dependent libraries. Note that this list is likely longer due to my use of the FWTools distribution - if you built your version from source it may look different, though the same principles apply.
To get the above code to work on my machine I had the following files in my output directory:
gdal14.dll
gdalconst_csharp.dll
gdalconst_wrap.dll
gdal_csharp.dll
gdal_fw.dll
gdal_wrap.dll
geos_fw.dll
geotiff_fw.dll
hdf5dll.dll
hdf_fw.dll
jpeg12_osgeo.dll
jpeg_osgeo.dll
libcurl.dll
libeay32.dll
libexpat.dll
libmysql.dll
libpq.dll
libtiff_fw.dll
lti_dsdk_dll.dll
mfhdf_fw.dll
msvcp71.dll
msvcr71.dll
NCScnet_fw.dll
NCSEcw_fw.dll
NCSUtil_fw.dll
netcdf.dll
ogdi_32b1.dll
proj.dll
sqlite3.dll
ssleay32.dll
szlibdll.dll
xerces-c_2_7.dll
zlib1.dll
zlib_osgeo.dll
Now these don't necessarily all have to live in the output directory - as long as they are on your path somewhere (e.g., \Windows\System32) you should be fine.
I know it's an old question, but I believe my answer might help someone.
I was able to successfully compile and run examples using c# gdal by doing the following:
Downloading GDAL sdk from http://www.gisinternals.com/ (64 bit in my case)
Executing the SDKShell.bat script to set the system environment paths, etc.
Creating a project in Visual Studio. And referencing all .net dlls (the ones that names end with _csharp.dll), located in \bin\gdal\csharp\ inside downloaded SDK
Setting platform target in Visual Studio project settings to x64 to get rid og bad image format exceptions. The last step wouldn't be necessary if I'd choosse 32bit version of SDK to work with.
I did not install fwtools at all. It seems like the last build of fw_tools is relatively old, and sdk is still maintained.
I know this is a reasonably old question now, but I found this in google after researching the same problem myself, so this means that for searches on this error this is still a very relevant page to update given it's still in the top 5 from the big G when the same problem is searched.
In my case it was the answers from "DeusExMachina25" and "Grzegorz Sławecki" that struck a chord.
I'm writing some software that makes use of the current builds of "sharp map" on NUGet (as of 24th of June 2016) and my software kept throwing the same gdal_wrap message as the OP originally reported, even though I'm using the GDAL package provided by the Sharpmap team.
I didn't realize that the NUGet installer for the package had installed a configuration class for me, but after reading through this thread and finding out that it does I went looking for it.
Sure enough I found the file 'GdalConfiguration.cs' in my project and added a call to it in an appropriate place in my project, expecting GDAL to be initialized correctly.
However, after I did this, I still had the same problem.
So, I set a break point on the beginning of the GDAL routine that had been added, and waited until the break point was hit.
I then traced through the method, and eventually found the following line:
var gdalPath = Path.Combine(executingDirectory, "gdal");
at around line 64 in the file.
Tracing through this, I noticed that the path being built was:
d:\geodata\maptest\maptest\bin\debug\gdal
but the NUGet installer had installed all the dependent assemblies in
d:\geodata\maptest\maptest\bin\debug
Exactly where I expected them to be.
I changed line 64 so that it now read:
var gdalPath = Path.Combine(executingDirectory, "");
and voila, the error went away and everything started to work.
I could have done things the other way too, and created a folder called gdal, then copied everything into that, but that then would have gotten deleted when I did a "clean" on the project.
Since the config class, set's up various environment variables based on this path, quickly changing that one line also fixes up the path for the GDAL data files , plugins and a few other things too.
You could try using Dependency Walker to see if there are any dlls that gdal_csharp is trying to grab but cannot.
Have you added the path to your GDAL libraries to your PATH environment variable? I downloaded my files from http://vbkto.dyndns.org/sdk/?_sm_au_=iVVqjsHS2n46WP00 and here's my path: C:\libs\release-1600-gdal-1-9-mapserver-6-2\bin.
To use the C#-bindings of GDAL you need an installation of FWTools (from http://fwtools.maptools.org/) as well as the most current binaries that match your system (from http://vbkto.dyndns.org/sdk/). Afterwards it is important to include the bin-directory of FWTools (example for 64bit-systems: C:\Program Files (x86)\FWTools2.4.7\bin) in your PATH variable as well as the necessary dlls (gdal_csharp.dll was mentioned in the question) in your Visual Studio project references. I outlined the complete processs here.
This process works on 32 bit as well as 64 bit systems, I tested it with VS 2010 and 2012.
Remove the path to python from the system variables. Because the main gdal paths conflict with python 27
Did you forget to:
GdalConfiguration.ConfigureGdal();
GdalConfiguration.ConfigureOgr();
Gdal.AllRegister();
Ogr.RegisterAll();
In my case the issue was:
I had 2 projects in my solution: ProjectA and ProjectB
I was executing ProjectA, and ProjectA was referencing ProjectB
ProjectB is the one that contained the references to both GDAL and GDAL.Native
ProjectA tried to find GDAL.Native's files under ProjectA\bin\Debug\netcoreapp3.1\gdal ... but in reality those files are under ProjectB\bin\Debug\netcoreapp3.1\gdal
Possible solutions:
Dirty solution: just copy the files from ProjectB under ProjectA\bin\Debug\netcoreapp3.1
Okayish solution: add the GDAL.Native package to each one of your "entry projects"
I don't like either of those solutions. This stuff happens under GdalConfiguration.cs, so maybe there is a way to modify it to find the correct path.
I feel like this is a question that's likely to have been answered already, but I'm having trouble finding it. Chalk it up to bad search terms, perhaps.
I've been working in Visual Studio 2005 Professional for about a month now, and thus far I've been using the built-in compile mechanism with mostly-default settings (the only thing I've changed with any real frequency is the build path). I'd like, however, to move to using more automated build techniques. To that end, I'd like to switch to using csc calls instead of hitting Ctrl-Shift-B or F5, so that I can include the lines in build scripts and other tools (like NAnt).
My question is, does Visual Studio or any third party tool provide a way to programmatically convert the compile setting ins VS to its csc equivalent? For example, if I have a project called SampleProject with the Output type: field set to Windows Application, it would look something like:
csc /output:winexe /target:SampleProject.exe *.cs
I know it's usually not terribly difficult to work this out by hand, but if there's a way to automatically pull it together, it's that much better.
Based on VS2010, but similar should work for other versions:
Tools > Options > Projects and Solutions > Build and Run
Change the "MSBuild project build output verbosity" to "Normal" (or higher)
Build, and bring up the Output window (ctrl+w, o).
Change the "Show output from" drop-down to "Build"
You should see an indicative csc line. Note this is not truly what it executed; it is a happy lie. IIRC it actually executes directly, and there are some corner-cases where what it outputs there is not quite the same as what you would need.
To start, this may be a useful link: http://www.ndepend.com/NDependConsole.aspx
As anyone who has used Visual NDepend may know, with NDepends you need to import project / solution files, and the corresponding output directories, namespaces, and assemblies are added to the NDepends project.
The problem I have, is I have TONS of these projects and solutions to add. It seems ridiculous to sit there for 45 minutes adding 300 solutions click by click. There must be a way to create an NDepend project file from a list of the paths to these solution / project files.
My first thought was to find the same information NDepends does (output directories, used namespaces and output executables dll's, etc) and programmatically create the NDepend project as a massive string. However, this seems like unnecessary work.
It would be nice if there was a way to invoke the command line and target specific projects, not output directories, as some of the projects have PostBuild tasks to copy assemblies to different directories, some projects specify the output directory as an upward relative path (ie ....), and so it isn't safe to assume that the output directory of a project is the same directory it is in.
Any ideas?
Stefan, I am the lead developer of NDepend.
We recently released NDepend.API that can do exactly what you are asking for.
NDepend.API overview
NDepend.API introduction
NDepend.API getting started
In the getting started section you'll find code example about how to use NDepend.API to create a temporary NDepend project initialized with assemblies generated from a Visual Studio solution.
You can also dig into the source code of Power Tools to see how to create or modify NDepend porjects. This source code can be found in: $NDependInstallPath$\NDepend.PowerTools.SourceCode\NDepend.PowerTools.sln