To be able to publish a single .exe I've added Costura/Fody package to my C# project. I've used this package before but now I get the following error message:
MSBUILD : error : Fody: AssemblyPath
"C:\Projects\X\MSBuild\obj\x86\Debug\X.exe" does not exists. If you
have not done a build you can ignore this error.
Finished Fody 4ms.
The strange thing is, is that intermediary X.exe is correctly build here:
C:\Projects\X\src\X\obj\x86\Debug\X.exe
The project I'm working on is fairly large. So we use a couple of MSBuild props files to put everything in the corect output directories. Both building from the command line with MSBuild and building from within Visual Studio works correctly. So I assume our props files are correct. Why is Fody looking in such a weird location for the intermediaries?
which MSBuild variable that Fody might use controls this Intermediary path?
Looking at the code that throws the exception, I see a very simple File.Exists check. It all stems from ProjectDirectory (in a WeavingTask) and you can check the places where the value is used here.
Since I have not used Fody, I can't tell you more than this. I would pay extra attention to the configuration files, since I don't see the ProjectDirectory being constructed anywhere, just injected from somewhere.
Related
I have an issue where, when I run a T4 template, it is picking up another copy of the EntityFramework.dll in the VS Common7 folder. That causes it to think that my DbContext class does not inherit from System.Data.Entity.DbContext.
When I debug the T4 template I get the following in the Immediate window.
typeof(System.Data.Entity.DbContext).Module.FullyQualifiedName
"C:\\Program Files (x86)\\Microsoft Visual Studio 14.0\\Common7\\IDE\\EntityFramework.dll"
However that path is absolutely nowhere in my Modules window. The proper EntityFramework.dll shows up there from my build output for the project I'm referencing.
I understand I'm leaving out some detail here, and I'll fill in more to answer questions, but I am just at a total loss as to what would cause Visual Studio to pull in another EntityFramework.dll instead of using the one that I'm providing it. This all runs fine, by the way, if I directly run the code in a command line app or if I set the templating tool to TextTemplatingFilePreprocessor and run the generated class.
The line of code this is all erroring on is:
Database.SetInitializer<FakeDbContext>(null);
FakeDbContext being nothing more than:
public class FakeDbContext: DbContext
{
}
The error I get is, given the dll issue, predictable:
Method System.Data.Entity.Database.SetInitializer: type argument
'FakeT4Dependencies.FakeDbContext' violates the constraint of type
parameter 'TContext'.
It thinks FakeDbContext is not a DbContext. Which it thinks because of the dll issue. Interestingly, the issue is a run time error, not an error at compilation of the text transform class. I can tell that by the stack trace, the type of exception (VerificationException), and the fact that it's an exception and not a compile error.
If I run the code straight through my command line, by the way, you get what you would expect for the type. And everything works fine.
typeof(System.Data.Entity.DbContext).Module.FullyQualifiedName
"C:\\Users\\jeffreyvest\\Code\\TestT4Dependencies\\TestT4Dependencies\\bin\\Debug\\EntityFramework.dll"
The issue only comes up when running it through the custom tool by saving the .tt file. Somehow VS loads things up just a bit differently and it wants to go off and use a different copy of the dll that I do not want it using at all. Incidentally, that copy is the same version of EntityFramework.dll. Just the fact that it lives in another assembly, and not the one referenced by my code, is throwing it off. The deepest mystery for me is the fact that it does not show that dll anywhere in my module list. It shows the other copy in my bin/debug of the project whose output I'm using. So it appears that's all getting bound up correctly then suddenly at the last minute somehow the type itself gets associated to a different dll. It would even be ok if it used nothing but that other dll in Common7 folder. It's the mix that's making it all go wonky.
EDIT
As an added fun twist, changing the assembly referenced in the T4 to use that Common7 copy of EntityFramework fixes the issue only when debugging the T4. When running it straight (just saving the .tt file) it still has the issue described.
I also put this together that I think really illustrates the issue.
typeof(FakeT4Dependencies.FakeDbContext).BaseType.Module.FullyQualifiedName
"C:\\Users\\jeffreyvest\\Code\\TestT4Dependencies\\FakeT4Dependencies\\bin\\Debug\\EntityFramework.dll"
typeof(System.Data.Entity.DbContext).Module.FullyQualifiedName
"C:\\Program Files (x86)\\Microsoft Visual Studio 14.0\\Common7\\IDE\\EntityFramework.dll"
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'm using TFS 2010 and have a TFS build setup to build our software. Everything is working just fine.
But, we are getting the following warning:
CSC: Assembly generation -- Referenced assembly 'mscorlib.dll' targets a different processor
This is because some of our code is marked as x86 only, and it is being built on an x64 platform. We cannot change the target platform because of third party software we link to.
Also we are targeting the 2.0 framework, which also cannot be changed at this point.
So, I want to simply suppress this error. Seems straight forward enough.
I simply edited the Build template, and added /p:NoWarn=1607. That works.
BUT!
We have ONE solution which is written in VB.net, instead of C#. This causes that one solution to fail with the following error:
vbc: warning number '1607' for the option nowarn is either not configurable or not valid
How do I disable suppressing this warning on that one solution in my TFS build?
I tried to use a <customPropertiesForBuild> tag in my TFSBuild.proj file but I'm probably not using it correctly.
I know I could simply add this to my project files, but we have 37 solutions, each with multiple project files, so I really don't want to do that.
I don't think you can control that suppression from TFS since it is MSbuild complaining during build (and TFS simply calls MSBuild and collects the results).
There's a specific property that tells msbuild to ignore this kind of warning. Simply add the following line to your top Propertygroup in the project file for those projects generating the warning:
<PropertyGroup>
...
<ResolveAssemblyWarnOrErrorOnTargetArchitectureMismatch>None</ResolveAssemblyWarnOrErrorOnTargetArchitectureMismatch>
</PropertyGroup>
You should be able to use Properties metadata on the VB solution's SolutionToBuild item to set NoWarn to an empty value just for that solution:
<SolutionToBuild Include="$(BuildProjectFolderPath)/../../MyVbSolution.sln">
<Targets></Targets>
<Properties>NoWarn=;</Properties>
</SolutionToBuild>
Try that and see if your VB solution will compile without errors.
You can provide a NoWarn Property to MSbuild in TFS Build. One idea also is to edit the build definition, in the "Process" Tab, explore the Advanced=>MSBuild Arguments, and then you supply this "/p:NoWarn=1607" without the qoutes. When you also queue a build, in Parameters Tab=>Advanced=>MSBuild Arguments, enter/p:NoWarn=1607.
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.
My problem seems to be relatively simple. I have a c# solution created in VS2010 with several projects with project references configured appropriately. I use MSBuild on our build machine which works fine, building in the correct order incrementally to be efficient. However, if I extend the interface (adding a public property etc.) and increment the AssemblyVersion of one of the projects that others depend on, it seems that MSBuild is unable to refresh the caching on down stream dependents and throws an error that it cannot find the previous version of the changed dll. Interestingly if I run the build again immediately afterwards, it tells me that the output hasn't changed and completes the build without error but I have no longer any confidence that it has done the right thing.
There is a file 'ResolveAssemblyReference.cache' that seems to hold the old reference and if I delete this from the obj/x86/Release folder before each build I never receive any errors but don't know if the output has/should have been rebuilt.
I would like to understand why MSBuild struggles with this and why on a second build it seems to report that the first build did actually work and that the targets are up to date.
Until I understand what is going on I am going to have to always force a rebuild of the entire solution to be certain I have compatible files.
Incidentally if I build in VS2010 I never seem to suffer this as I suspect it updates that cache appropriately each build.
Update:
I have found that my use of 'OutDir' on the command line for MSBuild seems to be to blame. If I remove this then the referencing seems to be resolved appropriately. However now I do not have my output copied to where I need it for deployment...