I'm working on getting my ASP.Net project working on Linux. I've been testing my code using XSP on windows, but now I am trying to make sure that I can develop and test on Linux as well. To that end I've gotten Ubuntu running and have MonoDevelop and MySQL running. I've downloaded the latest MySQL Connector/Net and I think I have it installed correctly.
There is no package that will automatically install the MySQL Connector/Net for distribution so I downloaded the 6.2.3 zip file from the MySQL website. Now I've already discovered the issue with case sensitivity because the zip file contains filenames in lowercase, and Mono expects them in uppercase. So I've changed the names of the files to MySql.Data.dll, and MySql.Web.dll respectively. I've also used gacutil to install both files to the GAC. Likewise I have added the files to the Mono Lib directory. The following files do exist on my machine:
/usr/lib/mono/gac/MySql.Data/6.2.3.0__c5687fc88969c44d/MySql.Data.dll
/usr/lib/mono/gac/MySql.Web/6.2.3.0__c5687fc88969c44d/MySql.Web.dll
/usr/lib/mono/2.0/MySql.Data.dll
/usr/lib/mono/2.0/MySql.Web.dll
I've also created package files so that I can add references to the the assemblies in MonoDevelop. The folder /usr/lib/mono/2.0 contains two .pc files that I added.
MySql.Web.pc:
Name: MySql.Web
Description: ASP Membership, Role and Profile providers powered by MySQL
Version: 6.2.3
Libs: -r:/usr/lib/mono/gac/MySql.Web/6.2.3.0__c5687fc88969c44d/MySql.Web.dll
MySql.Data.pc:
Name: MySql.Data
Description: Provides connectivity to MySQL databases
Version: 6.2.3
Libs: -r:/usr/lib/mono/gac/MySql.Data/6.2.3.0__c5687fc88969c44d/MySql.Data.dll
At this point I can use the assemblies in projects inside MonoDevelop. The Assemblies appear in the list of available assemblies when I edit the project references. The project now compiles without error inside MonoDevelop. However when I run the compiled web project in XSP the following error is displayed in the browser:
System.IO.FileNotFoundException: Could not load file or assembly 'MySql.Web.dll, Version=6.2.3.0, Culture=neutral, PublicKeyToken=C5687FC88969C44D' or one of its dependencies. The system cannot find the file specified.
What is fustrating is that originally the error was that it could not load MySql.Data.dll and now the error message is that it can not load MySql.Web.dll. Which means that I somehow fixed the problem I was having with the Data dll, and now I have the problem with the Web dll. I have gone and re-done I learned to fix the problem for the Data dll, but I am unable to get the Web dll working.
Unfortunately I'm still pretty new to Linux and Mono (but not to ASP.Net) and I've run out of things to try. Likewise I haven't found anything on Google to try other than what has been described above which leaves me asking for help.
Can anyone help me find out why XSP can't find the assembly and what I can do about it?
Thanks,
-Will
You can try setting some environment variables which should tell you where all Mono is looking for assemblies:
MONO_LOG_LEVEL="debug" MONO_LOG_MASK="dll" xsp2
Not a perfect fix (I don't know why its going wrong), but if you're in a hurry, copy MySql.Web.dll to the bin directory of your app.
Related
I have a project with assembly which refers to System.Threading.Tasks.Extensions, Version=4.6.28619, It's an old ASP.NET App hosted on IIS. After compilation, the app is running and everything is OK. After some time, the app throws an exception.
"System.Exception: Could not load file or assembly
'System.Threading.Tasks.Extensions, Version=4.1.0.0, Culture=neutral,
PublicKeyToken=cc7b13ffcd2ddd51.
After the recompilation and restarting the APP, everything works fine, but after a few hours, the exception is thrown again. What could be the problem?
I have tried to change web.config to use System.Threading.Tasks.Extensions in the correct version, but it didn't help.
Version=4.6.28619 is file version, not the Assembly Version. I did goodle on System.Threading.Tasks.Extensions history.
I found the 4.3.0 should be the correct version in your project.
Other version couldn't find 4.1.0.0 version dll like picture above. Package version >=4.4.0, using 4.1.1.0. <4.3.0, using 4.0.0.0.
Now you can follow the suggestions below to check the issue
Find the package System.Threading.Tasks.Extensions like my first picture.
If you have multi project, make sure all the projects using the same version package.
Delete the .vs folder
Check the web.confg/app.config file, and check the version of System.Threading.Tasks.Extensions, if there are duplicates, please delete them.
If the steps above not works for you, maybe the issue related to deployment. You can try the binding redirects.
I have Solution A which has a .NET Core 1.1 class library project. In the Package properties I filled all NuGet fields and selected to create the NuGet upon successful build. This project builds just fine and the NUPKG is created. BTW How can I automatically copy the generated NUPKG to a local directory (my own repository)?
Then I have Solution B which is an ASP.NET Core 1.1 web application. In it I browse to my local repository (where I have manually copied the NUPKG built by Solution A) and install my SolutionA.MyPackage into the web application. VS.2017 says it was successful at installing it. I see it listed in the project's NuGet dependencies.
However, when I try to use ANY of the objects defined in that NuGet package I get a red highlight saying it is not found as if there was no NuGet or assembly reference to that DLL but there is!
What is causing this Visual Studio generated Nuget package to be installed and yet act as if it has not even been referenced?
UPDATE - CSPROJ TARGET
As for copying to my local repository, I added this to CSPROJ but it was not working (somebody had suggested it as I put it). I finally figured out why it did not work, the ItemGroup must be inside the Task.
<Target Name="CopyPackage" AfterTargets="GenerateNuspec">
<ItemGroup>
<MyPackageFiles Include="bin\Release\PackageId.*.nupkg" />
</ItemGroup>
<Copy SourceFiles="#(MyPackageFiles)" DestinationFolder="D:\My Repository\MyNugget\Publish" />
</Target>
UPDATE NuGet Inspection
I opened the NUPKG with NuGet Package Explorer and it shows this more or less:
content\
Properties\
launchSettings.json
Views\
Shared\
rest of my stuff here
contentFiles\
any\
netcoreapp1.1\
Properties\
launchSettings.json
Views\
Shared\
rest of my stuff here
lib\
netcoreapp1.1 (.NEtCoreApp, Version=v1.1)
MyPackage.dll
UPDATE 3
Since NuGet seems to have stopped working (used to work well earlier) I opted for using an Assembly Reference rather than a NuGet (for now). In this situation something odd happens, when coding I can reference ALL the objects in the referenced assembly (former NuGet) and therefore no compilation errors on the main project BUT when I then run the web application I get an internal error because it says
FileNotFoundException: Could not load file or assembly
'MyPackage, Version=0.0.3.0, Culture=neutral, PublicKeyToken=null'.
The system cannot find the file specified.
Unknown location
Which is strange because in the Solution Explorer I see the assembly reference and when I click on it (main application) I can navigate to all the objects that I have defined in that assembly. Why it cannot find it anymore?
It is working again (as it was before!). Today I could open the solutions but when I tried to download an extension (Tools | Extensions) I got an error message about an Access Denied or something like that. It has happened before since I installed to VS.2017.
Of all the Visual Studios I have used since 2002 this has been the most unstable! (and I have update 15.2).
When I saw this error happening again I knew how to get rid of it and thought, "hey, maybe that is what is keeping the NuGet package to be installed but not found or the problem with a direct assembly reference".
So I went to my C:\Users\AppData\USER\Local\Microsoft\VisualStudio\15.2* folder and removed it completely.
After that I the ACCESS DENIED issue went away with the side effect that I had to reinstall all extensions again. I attempted again to install my own NuGet, it did so successfully and as expected (was not happening during the long glitch) the objects were found and the web application worked again.
We have to deploy our web project on several (possible 10) servers , We've developed Nant script that doing the Job , but We've face with problem , that Microsoft.Web.Infrastructure.dll that is one of the dependencies doesn't deployed what ever we do.
Could anyone please explain how can add reference to this dll , and mark it copy local or something ? I'll try to explain what's hapening , when I am adding reference to this dll to our proj , the reference added to web.config like :
<assemblies>
<add assembly .... blah blah />
</assemblies>
This means that assembly should be in GAC , right ? I can see it well if I am clicking on Property Pages in visual studio , and going to refereces tab , I can see that this Dll is in Gac.
Ok , the following command
gacutil.exe -l Microsoft.Web.Infrastructure returns with no Result !
So where is this assembly stored ? How the magic is done by Microsoft ???
How can I remove it from GAC ???
Anyone ?
PS. One of the possible resolutions that I've found on web. Is to run Package Manager and install it from there again ... but for me it's not a options , we aren't connected to internet for security reasons.
If you've developed against MVC assuming its installed in the GAC why don't you just install it on the target server via http://www.asp.net/mvc/mvc3
The copy local solution is great if you've got a proj file to work with but you don't as you opted for a website project which is all sln and web.config.
You could add a reference via your websites property page (from your nuget package)
You sound like you already have nuget package but if not you just right click on the bin folder and manage packages - Microsoft.Web.Infrastructure - install
If you add this package reference to your bin folder you'll see a new file:
bin\Microsoft.Web.Infrastructure.dll.refresh
This just contains a link to actual dll in the package - ..\packages\Microsoft.Web.Infrastructure.1.0.0.0\lib\net40\Microsoft.Web.Infrastructure.dll
The dll will get copied over to the bin folder at build time.
I would suggest you use webmatrix / web platform installer to install the DLL on each of the servers.
I have an almost empty ASP.NET MVC4 project referencing a 64 bit managed assembly, which has a set of unmanaged dependencies.
The managed assembly is referenced the normal way through references.
The unmanaged dependencies are copied to the bin folder on a post build event - and are present when the web app is started (this has been verified).
The problem is that I get:
Could not load file or assembly 'msvcm80.DLL' or one of its dependencies. A dynamic link library (DLL) initialisation routine failed. (Exception from HRESULT: 0x8007045A)
This is one of the unmanaged dependencies. The full list is:
iconv.dll
lbm.dll
libeay32.dll
msvcm80.dll
msvcp80.dll
msvcr80.dll
The managed dll is built against x64 and all the dependencies are also x64 (verified by using Dependency Walker).
Now I have also created a blank console app, a windows form app and a self-hosted Web Api which contains the the same code (for firing up instances using the managed assembly) and they all work fine (when forcing the build target to be x64).
Using Fusion Log (clearing it first, then loading the web app and refreshing the log viewer), I can see that there are problems loading:
iconv.dll
libeay32.dll
lbm.dll
All of them have similar log files:
LOG: Attempting download of new URL file:///C:/Windows/Microsoft.NET/Framework64/v4.0.30319/Temporary ASP.NET Files/root/3b2d5b3e/b1b5f1f5/iconv.DLL.
LOG: Attempting download of new URL file:///C:/Windows/Microsoft.NET/Framework64/v4.0.30319/Temporary ASP.NET Files/root/3b2d5b3e/b1b5f1f5/iconv/iconv.DLL.
LOG: Attempting download of new URL file:///C:/.../bin/iconv.DLL.
LOG: Assembly download was successful. Attempting setup of file: C:\...\bin\iconv.dll
LOG: Entering download cache setup phase.
ERR: Error extracting manifest import from file (hr = 0x80131018).
ERR: Setup failed with hr = 0x80131018.
ERR: Failed to complete setup of assembly (hr = 0x80131018). Probing terminated.
So it actually figures out that the dependencies are in the local bin folder, but it cannot use them for some reason.
What does the error "Error extracting manifest import from file (hr = 0x80131018)." mean?
The dependencies are not in GAC and they are not registered using regsvr32 (not COM).
What puzzles me is that is works fine outside IIS (I even tried to set up the credentials on the app pool to be the same as the local network credentials - which did not make a difference, of course).
Any good ideas of how to debug this issue?
EDIT:
I am now able to run the ASP.NET site on my local developer machine, but not when it is deployed onto another server.
The "fix" for my local machine, was to remove the msvcm80.dll (C runtime) from the bin directory. The assembly is (probably) still needed, but is looked up somewhere else (presumably because I have the "correct" version of CRT (distributable) installed in WinSxS).
Digging into that, I see that the managed assembly is supposedly dependent on msvcm80.dll version 8.00.50727.6195 (x64), but that particular version is not installed on my local system (I only have it in a dependency folder) - but I do have a newer one in WinSxs (8.00.50727.6910).
So which one is IIS picking up when not adding it directly in the bin folder?
2nd EDIT:
So it looks like lbm.dll has a direct dependency to msvcr80.dll, but it also has a dependency to iconv.dll which again has a dependency to msvcr80.dll. However, according to Dependency Walker (depends.exe), those two dependencies are not resolved from the same directory (even when they have the same version!).
If I make sure that the indirect dependency is in the PATH environment variable and the 2nd dependency is in WinSxS it works. This is obviously not good enough, but I cannot figure out how to enforce that the direct and indirect dependency is loaded from a single location/file.
Using a tool like Dependency Walker you will find that lbm.dll and its dependencies only depend on msvcr80.dll and not msvcp80.dll and msvcm80.dll even though these two files are included in the Microsoft.VC80.CRT.manifest used by lbm.dll to load the correct version of the Visual C++ 2005 runtime library.
Removing msvcp80.dll and msvcm80.dll from you bin folder should fix your problem.
Immediately after we upgraded to visual studio 2010 and the 4.0 framework our trunk build started breaking with the Could not load file or assembly error.
We determined that a 3.5 project couldn't reference a 4.0 project else we'd get this error because, as the error states, This assembly is built by a runtime newer than the currently loaded runtime and cannot be loaded.
We've since resolved this and the trunk has been building fine.
I recently did a branch and tag, however, and suddenly this error has resurfaced when I try to build the branch; except the error is regarding one of our own .net 4.0 project's reference to System.Configuration DLL.
Towps.Namespace.MyService.csproj in Core.Dev\Towps\Projetcs\Application\MyService:
RG0000: Could not load referenced assembly
"C:\Windows\Microsoft.Net\assembly\GAC_MSIL\System.Configuration\v4.0_4.0.0.0__b03f5f7f11d50a3a\System.Configuration.dll". Caught a BadImageFormatException saying "Could not load file or assembly 'C:\Windows\Microsoft.Net\assembly\GAC_MSIL\System.Configuration\v4.0_4.0.0.0__b03f5f7f11d50a3a\System.Configuration.dll' or one of its dependencies. This assembly is built by a runtime newer than the currently loaded runtime and cannot be loaded.". in ResGen(0, 0)
I tried setting the specific version property on that system.Configuration DLL ref to true. I can see in it's properties that the runtime version is v4.0.30319 and the Version is 4.0.0.0. The path to the DLL ref is C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.0\System.Configuration.dll which to me looks fine.
The target framework for the csproj file that CrusieControl is using MSBuild to try to build is targeting framework 4.0. Again seems fine.
It builds in the IDE for both trunk & branch. Cruise Control build it in the trunk. The branch build fails when CrusieControl tries to build.
Any ideas what could be happening?
It could be an MSBuild mismatch but I've scanned the config files and msbuild proj files that CruiseControl is using and there are no references to older MSBuilds; which makes sense since all those were updated to get the trunk working.
The branch was simply a copy of the trunk so I'm having difficulty determining what could be the difference!
It turns out that after I branched, all the .proj files in my branch build directory that cc.net uses were back to using ToolVerison="3.5".
I thought I committed all the ToolsVersion="4.0" proj and config changes to the trunk from which I made the branch; evidentially not.
The difference could easily be hint paths no longer lining up on the new branch. However there's not a log to go on in your description. What are the command line options you are passing? In ccnet.config and also any others that may get in if ccnet.config is pointing at a build script that calls msbuild instead of directly to a .sln or .csproj file.
Turn on /v:d for the msbuild on BOTH and then compare the reference resolutions (or build order, etc..) for that assembly or other ones involved/near it.
Also are you providing the path to msbuild on both?
msbuild4="C:\WINNT\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe"
<msbuild>
<executable>$(msbuild4)</executable>
in your ccnet.config?
I've seen it report the 2.0 build executable during a msbuild4 /tv:3.5:
<Message Text="MSBuildToolsPath:$(MSBuildToolsPath)" />
<Message Text="MSBuildToolsVersion:$(MSBuildToolsVersion)" />
MSBuildToolsPath:C:\WINNT\Microsoft.NET\Framework\v2.0.50727
MSBuildToolsVersion:2.0
so that didn't seem very useful.
I'd like to see the config blocks for both branch and trunk.
I know I had some paths in the buildscript that failed in my branch because there was a hardcoded path that would not be valid for the branch. I had to adjust the ccnet.config to pass in arguments for those items to override for the branch.
Please check .net framework version supported by your client. For example sharepoint2010 will not support dll built by 4.0 or higher .net framework. It will support only 3.5 or below.
A bit late I know, but if anybody else has this issue, try adding the RuntimeVersion into your .dna file if it does not already exist.
<DnaLibrary Name="PROJECTNAME" RuntimeVersion="v4.0">