I am using ABCpdf.net to merge few pdf files. but I am getting below error while creating object of Doc class...
ABCpdf 64-bit core engine version 10105 is older than ABCpdf .NET version 10.1.0.7.
There is no other error information available in exception snapshot. Code which is throwing error...
Doc mergedPdf = new Doc();
I am using ABCPdf.net version 10.1.0.5 and have no reference of ABCpdf.net version 10.1.0.7.
How to resolve this?
Sorry for the trouble. I found the cause. Previously my solution was using 10.1.0.7 version that was downgraded to old version 10.1.0.5 due to some business requirements. ABCpdf.net version 10.1.0.7 binaries were copied to bin/debug folder and forcing this exception to be thrown.
Somehow cleaning up solution was not helping.
Solution: deleted bin/debug folder and rebuild the entire solution fixed the issue.
thanks...
The .dll version in production machine and the .dll version in developing machine is different; reinstalling .dll will fix the problem.
Related
I have already installed VS2017 Enterprise 15.6.4. Recently installed .NET Core 2.1.101 SDK from official site
I was expecting .NET Core 2.1 as one of the target framework available if I create console or asp.net core application. Can someone help me understanding what I am missing here.
As suggested in comments, I installed 15.7 preview 2. Still no luck and same issue.
I have faced the same problem. I solved this by installing the right SDKs with Runtime for .NET Core 2.1.
Basically to run/create 2.1 projects from VS Preview, you need to install the "2.1.300" (not 2.1.4) .NET Core SDKs and Runtime. https://www.microsoft.com/net/download/dotnet-core/sdk-2.1.300-preview1 (this includes required Runtime already)
The good explanation of this misleading with versions i found here https://github.com/dotnet/cli/issues/8309 (dasMulli commented on Feb 24).
In case this helps someone else... After installing VS 15.9.2 my project that was working fine with 2.2 preview-3 stopped working. VS could not see the preview SDK. I could build the solution using dotnet.exe but not VS.
To solve this I created a global.json at the root folder of this solution pointing to the preview sdk. That allowed VS to see the preview version.
This is a change of behavior in VS between 15.8.x and 15.9.x.
To create the global.json you can navigate to the desired folder and type this:
dotnet new globaljson
Make sure dotnet PATH variables are in correct order
If you have installed an SDK for a different system architecture (e.g., if you installed 32-bit/x86 SDK on a 64-bit computer), then a new entry in the PATH variable would have been created for that specific location (e.g., C:\Program Files\dotnet or C:\Program Files (x86)\dotnet).
The problem is that Visual Studio, when searching for installed frameworks, will stop at the first PATH variable entry it finds that contains an SDK. So, if the first version you installed used an incorrect architecture, then you'll have to adjust the position of those entries before any of the correct SDKs will appear in the Target Framework drop down.
Source: this absurdly-hard-to-find comment within issue #8309.
TL;DR: Make sure the first "C:\Program Files\dotnet\" entry in your path variable you see in the list matches your system architecture:
64-bit = C:\Program Files\dotnet\
32-bit = C:\Program Files (x86)\dotnet\
Make sure that Visual Studio 2017 is up to date. Go to "Tools" -> "Extensions and Updates" to install visual studio updates. This resolved the issue for me.
I have faced the similar situation I tried to install the preview version of the dot net but it did not help.
However after I updated visual studio (from 15.8 to 15.9.6 ).
I Could see dot net core 2.1 in the target framework.
Updated to Latest VS 2017 and installed latest .Net Core SDK.
Changed global.json to point to latest version installed.
This resolved for me.
I had faced the similar issue. I then just updated my Visual Studio 2017 to 15.9.16 version and restarted the system. The problem got resolved.
I was facing the similar issue, I uninstalled the .Net Core 2.2 runtime and then from the below link:
https://dotnet.microsoft.com/download/visual-studio-sdks?utm_source=getdotnetsdk&utm_medium=referral
Install the .Net Core 2.2 Visual Studio SDK, Restarted the Visual Studio and my issue got resolved, .Net Core 2.2 is now getting listed in Target Framework list in the project properties in Visual Studio 2017 Version 15.9.16
I created a new project under .net core 2.1 and it was ok but in my old project have not appeared. So I opened both ".cproject" files and compared them together and found the problem.
Open your project's ".cproject" file in a text editor then replace below line
<TargetFramework>netstandard2.1</TargetFramework>
with this one:
<TargetFramework>netcoreapp2.1</TargetFramework>
I am using ReactJs.NET in a ASP.NET MVC 4 project. I have disabled the fallback to MSIE javascript engine by specifying this in my ReactConfig.cs that is called on app start:
ReactSiteConfiguration.Configuration.SetAllowMsieEngine(false);
This works on my developer machine but not in production. The exception that is thrown is:
Failed to initialise ClearScript V8. This is most likely caused by the native libraries (ClearScriptV8-64.dll and v8-x64.dll) missing from your app's Bin directory, or the Visual C++ runtime not being installed
I have ensured that the ClearScript.V8 folder (with ClearScriptV8-64.dll and v8-x64.dll) is copied across to the production server and the bin folder so I am currently looking at whether the Visual C++ runtime is missing or not. I downloaded and installed the Visual C++ Redistributable for Visual Studio 2015 located here: https://www.microsoft.com/en-us/download/details.aspx?id=48145 but the same exception is thrown.
Is there something obvious I am missing here? Is it the wrong Visual C++ runtime that I have installed?
Are those DLL files in a ClearScript.V8 folder? They need to be at bin\ClearScript.V8\ClearScriptV8-64.dll for example.
Alternatively, you can try out the release candidate of ReactJS.NET 3.0, which uses a newer version of JavaScriptEngineSwitcher that changes how V8 is loaded and no longer requires the DLL files to be manually copied over. There's currently no documentation on ReactJS.NET 3.0 but it's pretty similar to the current 2.x version. I'll be working on the documentation for the final release soon.
In my case I managed to resolve this by installing the Visual C++ 2013 runtime, this was the only version that actually worked in this case. I had no luck with neither 2012 or 2015.
I found the answer here:
https://github.com/reactjs/React.NET/issues/80
and the comment that helped me was:
Just another note, ClearScript 5.4.4 readme says VS2015 or 2013 C++
runtimes will work, but in my experience, it only worked when 2013's
was present.
I tried to change the Target Framework on my app recently from .NET Framework 4.5 to 4.5.2, but if I do I get the following error when trying to build: "'Forms' is not a member of 'Windows'" (that is, System.Windows.Forms). Changing to 4.5.1 works normally. I'm using Visual Studio 2013 Ultimate.
I had this error when changing to 4.5.2.
In my case the error was related to a MessageBox ... I replaced: "Windows.Forms.DialogResult.Yes" (which caused the same error message) with "System.Windows.Forms.DialogResult.Yes" which did the trick.
I had the same problem, me too with Windows.Forms.DialogResult enumeration values.
The project automatically imports System and System.Windows.Forms namespaces and worked fine up to 4.5.1.
In 4.5.2 I had to remove Windows.Forms. and just leave DialogResult.Ok (or whatever else) in my code, it seems to be a problem with namespaces resolution.
Make sure that you add System in front of the Windows.Form.
I ran into this with an application still targeted to .NET 4.0, where it failed on one (new) build server, but ran on my older ones.
I narrowed it down to the .NET 4.0 Targeting Pack only being installed on the old build servers. Targeting pack is included in Visual Studio, or the Windows 7.1 SDK. It is for some reason not distributed separately, and with support ending for .NET 4, 4.5 and 4.5.1, I don't suspect this is likely to change. Because my older servers have been around a couple years, they've gone through in-place upgrades and so had the targeting pack already.
When you install Windows 7.1 SDK on Server 2012R2, it complains something to the effect of "A pre-release version of .NET 4 is installed, please install the RTM version". As far as I can tell, it's simply because a newer version) is installed -- Server 2012R2 comes with 4.5.1. I tried to uninstall all newer versions, but was unable to get the SDK to install the targeting pack.
So to install:
Download the Windows 7.1 SDK ISO image
Unzip it
Run Setup\MTPack\netfx_dtp.msi EXTUI=1
You should now have a %programfiles(x86)%\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0\ folder with the 4.0 stuff.
(EXTUI=1 bypasses the restriction that it can't be installed separately).
This allowed me to compile projects still targeting 4.0 (or re-build old revisions/branches that were targeting it at the time).
I'm trying to build a console app to test out redis/mono communication. I've been hitting a brick wall using Monodevelop 4.0 (Xamarin Studios)+Nuget Port to work with ServiceStack.Redis on mac os.
All the solutions I've found online only say, change the ".Net 4.0 Client Profile" into ".Net 4.0 full" on visual studios. I haven't found a related function on MonoDevelop, not even sure if such an option exists. So no help there.
The error I am getting is:
"The type or namespace name `RedisClient' could not be found. Are you missing a using directive or an assembly reference?"
The screencap below shows the missing references, even though it is clearly in the reference folder :(. It is very puzzling.
Has anyone had a similar problem? Any help would be appreciated.
I think this is generally an issue with lagging version numbers on Mono.
For example, here's an example that can reproduce the issue:
Your ServiceStack.Redis is compiled against ServiceStack.Interfaces -> 3.9.45.
But you've actually pulled the latest 3.9.48 versions of:
ServiceStack.Interfaces 3.9.48
ServiceStack.Common 3.9.48
ServiceStack.Text 3.9.48
Mono will have problems forwarding old ServiceStack references 3.9.45 to 3.9.48.
So, recompiling from source will resolve the issue.
Or, ensure all your references are using the same version number by opening up all ServiceStack.*.dll (as you've done) and ensure there are no lagging version number references.
Similarly, I had a problem with ServiceStack.Logging.NLog compiled against 3.9.44 packages which lead to various TypeLoadExceptions on Mono when the head version of ServiceStack.* is 3.9.48.
So after hair tearing fighting with the MonoDevelop IDE and nuget. I just resorted to building the Servicestack.redis from source in MonoDevelop, and copied over the output DLLs. This worked without a problem.
It seems either that monodevelop doesn't like the Dlls from nuget, or that the nuget port has some bugs with DLl references. Either way, I don't know the specifics, but there is a solution around it by building servicestack components from source in MonoDevelop.
I was having this same issue with Xamarin Studio 4.0.12 + NuGet Port running against Mono 2.10.9.
Yesterday I decided to try to get OrmLite working & when I went to add the package, I saw that there were ServiceStack updates available (to version 3.9.66.0 from 3.9.63.0). Installed the updates and added the OrmLite package and I started getting the same error...
"The type or namespace name 'OrmLiteConnectionFactory" could not be
found. Are you missing a using directive or an assembly reference?"
The weird part was Intellisense was working (I could fully qualify OrmLiteConnectionFactory in the IDE and it would find it fine) but it would not build. Just like you, I also saw in Assembly Browser that my ServiceStack DLLs were referencing previous versions of some of the other ServiceStack projects.
Upgrading to the latest Mono release (3.2.3 atm) solved the issue for me. Hallelujah! Not sure why I was using Mono 2.10.9 to begin with.
I recently upgraded abcPDF from v8.1.0.7 to v8.1.1.1 (and then later from v8.1.1.1 to v8.1.1.2). After the upgrades, I got errors similar to the following whenever I tried to generate a PDF:
"Gecko engine failed to render the page: Gecko engine crashed.; Gecko
engine crashed...;"
"Failed to add HTML:Gecko engine crashed.; Gecko
engine crashed.; Gecko engine crashed..."
We're using the Gecko engine (instead of the default MSHTML engine) to render PDFs. We didn't get the error message until immediately after we upgraded abcPDF. This is in a .Net Framework 4.0 / C# / ASP.Net web application, hosted on 64-bit Windows Server 2008 R2.
How do I get past this error?
Here's how I solved the problem (in case anyone out there has the same issue): I had originally installed the newer version of abcPDF without uninstalling the old version, first. To get past the error, here's what I did:
Uninstalled all versions of abcPDF from the server;
Confirmed that the GAC (c:\windows\assembly) did not contain any copies of abcPDF assemblies
Reinstalled the latest version of abcPDF (8.1.1.2, at time of writing)
Confirmed that all web.config files referenced the 8.1.1.2 version of the abcPDF assembly.
Once I did all of the above, I was able to render PDFs without errors once again.