I have installed TXTextControl .NET 15.1 with a valid license key on a brand-new Windows Server 2016, and I have installed Visual Studio Build Tools 2017 including .NET 4.6.2 and .NET 4.7.2.
When I build my C# project (targeting .NET 4.6.2), I get the following error:
(CompileLicxFiles target) ->
licenses.licx(1): error LC0004: Exception occurred creating type 'TXTextControl.ServerTextControl, TXTextControl, Version=15.1.800.500, Culture=neutral, PublicKeyToken=6b83fe9a75cfb638' System.DllNotFoundException: The TX Text Control kernel DLL file could not be found.
The error The TX Text Control kernel DLL file could not be found hinted at something missing in the GAC, which I then proceeded to check out.
Running the gacutil.exe that came with .NET 4.7.2 indicated that the necessary registrations for
txkernel.dll
txic.dll
txtools.dll
were not there.
I then went on and installed them manually, both the x86 and AMD64 versions, from their respective locations:
C:\Program Files\The Imaging Source Europe GmbH\TX Text Control 15.1.NET\BrowserBin\txkernel.dll
C:\Program Files\The Imaging Source Europe GmbH\TX Text Control 15.1.NET\BrowserBin64\txkernel.dll
etc.
But it still didn't work!
I then contacted support, but their reply was that my license was no longer valid for support, so they basically refused to answer any questions about the product.
After a while I then got the supporter to say that the company never test OLD versions of TXTextControl on NEW versions of Windows, so my best bet would be to purchase a new license.
Since the license is pretty expensive, and our (PERPETUAL!) license is perfectly valid for running the product, I am determined to find a solution to this issue.
Can anyone help me?
After some struggling, I found the solution: Install .NET 3.5 BEFORE installing TXTextControl .NET.
My hypothesis is that the TXTextControl installer fails to check the exit codes, when running gacutil.exe, so it doesn't detect that the registrations have failed.
This means that the recipe for solving this problem (which I post here for Bingle to pick up), is to:
wipe any GAC registrations you may have made in an attempt to manually install the TXTextControl DLLs
uninstall TXTextControl .NET
go to Server Manager and "Add Roles and Features", and then on the "Features" pane, you put a checkmark next to ".NET Framework 3.5 Features" (which causes a single checkmark to be in ".NET Framework 3.5 (includes .NET 2.0 and 3.0)")
reinstall TXTextControl .NET
After this was done, I could build my code!
From having similar sounding issues with the ASP.Net version, make sure that you also have Visual C++ Redistributable Packages for Visual Studio 2013 installed as since v25 this has been required and for any machines that don't already have that installed then the ASP.Net version throws similar errors about txic.dll.
Related
I have a Windows 2016 server that I am setting up as a build server. It will be setup to use MSBuild to build a .NET 4.6.1 Web API project I am using MSBuild version 15.0, and using TeamCity version 2018.1, however I do not believe TeamCity is really involved in the issue, as I get the issue by doing an MSBuild manually/directly against the code
Windows 2016 has .NET 4.7, so I installed the .NET 4.6.1 targeting pack and .NET 4.6.1 SDK. In the build step in TeamCity, I have a parameter to MSBuild of "/p:TargetFramework=net461" But in the build logs, and when I run MSBuild manually/directly against the code, I get the following error:
HttpExtensions.cs(44, 24): error CS8137: Cannot define a class or member that utilizes tuples because the compiler required type 'System.Runtime.CompilerServices.TupleElementNamesAttribute' cannot be found. Are you missing a reference?
HttpExtensions.cs(44, 24): error CS8179: Predefined type 'System.ValueTuple`2' is not defined or imported
When I am on my development machine with Visual Studio 2017 installed, the project builds without issue. My development machine is Windows 10, but the other major difference is that the Windows 2016 server does not have Visual Studio. My thoughts are this has something to do with Windows 2016 having the primary .NET version as 4.7, and installing Visual Studio would maybe fix the issue. But I really want to avoid installing Visual Studio on the Windows 2016 server
Any ideas/feedback ?
Either or both of the following errors implies that you are trying to use ValueTuples without having either a reference to System.ValueTuple or having a version of mscorlib.dll from NET 4.7 or higher.
error CS8137: Cannot define a class or member that utilizes tuples because the compiler required type 'System.Runtime.CompilerServices.TupleElementNamesAttribute' cannot be found. Are you missing a reference?
error CS8179: Predefined type 'System.ValueTuple`2' is not defined or imported
The simple solution is to add a nuget reference to the most up to date version of System.ValueTuple and your project will then build in NET 4.6.1. See here for more details.
The reason why this works locally for you, but doesn't on your build machine is slightly more complex (and entirely theoretical, since I don't have machines of those specs to test it out).
See this question for an explanation of how MSBuild works when it doesn't have the correct targeting pack available.
Your build machine was building your project as requested. MSBuild 15.0 saw that it needed to build a project to target NET 4.6.1, found the correct targeting pack / SDK and pulled in a reference to the NET 4.6.1 mscorlib.dll, and correctly found that with this dll it had no reference to ValueTuples and couldn't build your project.
My guess is (and I'm happy to be wrong here) that you don't have the targeting pack / SDK for Net 4.6.1 installed on you local machine and as such msbuild defaults to the NET framework associated with 15.0 which is (I think) NET 4.7. This means that the mscorlib.dll that gets used is the NET 4.7 one which does contain an in-built ValueTuple type.
Ordinarily adding the nuget reference would cause a conflict for your local build (you have 2 structs from different sources with the same name (ValueTuple)), but Microsoft appear to have done something clever so that the version from the Nuget package is ignored if ValueTuple is contained in the mscorlib.dll. See comments here.
This all feels very nasty, and I personally would prefer if MSBuild threw a hard error if it couldn't find the correct targeting pack, but that's not how it works currently.
Thanks to #Ross Gurbutt for pointing in me the right direction. While it's easy to find through googling about the issue related to referencing System.ValueTuple when it's .NET 4.6.1 versus 4.7, what was confusing was that it was compiling successfully on my local without a reference. Nonetheless, I added a reference to the nuget package, and the Windows 2016 server with MSBuild v15.0 was able to build the Web API project successfully
I am doing maintenance work on a VS2010 C# project built against .net v3.5.
I recently changed the project Target Framework properties to the latest version listed (v4) - due to an expectation of using a version of .net that is actually included in Win10 by default - and rebuilt without any apparent issues.
Unfortunately the embedded dependency in the generated .exe is still for .net v2.0.50727 (which is what is reported for v3.5 AFAIK) and the target machine (a clean install of Win10) is asking to install .net 3.5.
Using MS VS2010 v10.0.40219.1 SP1Rel.
Unfortunately upgrading the build tools isn't an option (building the program with VS2015 works just fine).
I have gone googling but don't seem to have found any similar reports.
Based on some of the comments already posted, I seem to have not made myself entirely clear - hopefully the following will help.
1) the intention/requirement is to be able to install this app on a clean install of Win10 without needing any further downloads. (installing .net 3.5 is easy to do, just not what is wanted)
2) the ultimate build environment for this is automated, visualized and not in my control and therefore upgrading the tool chain is a major pain that I'd like to avoid if possible.
3) AFAIK there are no third party libraries involved. All of the listed references (dll's) are v4.0.30319.
4) this is a XAML-based development, one part of three projects in the solution - the other entries are the installer and a C# custom installation library. As far as I can tell everything is set for .net v4.
Unfortunately the embedded dependency in the generated .exe is still for .net v2.0.50727 (which is what is reported for v3.5 AFAIK) and the target machine (a clean install of Win10) is asking to install .net 3.5
So there is some dependency in your project that targets that version of .NET. It could just be that you need to Build > Clean Solution and with a Build > Rebuild Solution the problem is solved.
Otherwise, assuming some library does require some .NET 3.x library, the installation request is entirely correct. Windows 10 does not have an option for installing .NET 2.0 and another for installing .NET 3.5. If you search for Turn Windows features on or off you will see this:
Any dependency on a .NET 2.x-3.x library will trigger the activation/installation of the first feature in the dialog.
As far as I can see, you have 2 options:
Move everything to a framework supported by Microsoft, most preferably .NET 4.7.2 given support and security.
Deal with the installation process and understand that Microsoft does not install these versions of .NET in purpose. You can, however, add these installers as a prerequisite and even bundle them with your installation, but that won't help much.
Thanks to all who have tried to help me!
The issue has been resolved.
There appear to have been two causes for this issue and my confusion:
it turns out that the blank install of Win10 that the testing was being performed on was not entirely clean - the pre-installed network drivers/utilities from intel also had a .Net v3.5 dependency...
one of the embedded resources in the project was effectively a uncompressed tar-ball containing a number of files; including an executable that had the dependency on .net v3.5 - this was a binary blob stored in svn so the content was had not been updated for several years (ie well before my involvement) ...
With both of these issues addressed it would appear that my problem is solved, so once again thank you for your feedback, suggestions and patience,
PeterT :->
I'm running Unity 2018.1.7f1 on Windows 10 Insider Preview 10.0.17711, and suddenly I can't deploy a debug version of my app to HoloLens. It seems to be an issue either with the latest OS preview, or the new version of Unity.
Error DEP8000 : Unexpected deployment failure : RemoteCommandException
: Windows cannot install package Template3D_1.0.0.0_x86__pzq3xp76mxafg
because this package depends on a framework that could not be found.
Provide the framework "Microsoft.VCLibs.140.00.Debug" published by
"CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond,
S=Washington, C=US", with neutral or x86 processor architecture and
minimum version 14.0.26428.1, along with this package to install. The
frameworks with name "Microsoft.VCLibs.140.00.Debug" currently
installed are:
{Microsoft.VCLibs.140.00.Debug_14.0.26128.0_x86__8wekyb3d8bbwe}
I have the latest VS2017 installed all the Windows SDKs installed up to the current 10.0.17134.0, and the latest HoloLens emulator/VS2017 templates. I've tried adding the missing framework using PowerShell (Add-AppxPackage). Stumped.
The answer is here:
https://www.microsoft.com/en-gb/download/details.aspx?id=30135 - Microsoft .NET Framework Repair Tool. It immediately found and fixed the issue.
I had same issue. Then I remembered that even in Microsoft's tutorial release version is used instead of debug.
I'm referring to following text:
Using the top toolbar in Visual Studio, change the target from Debug to Release and from ARM to X86.
You can find same instruction in both tutorials:
MR Basics 101
MR Basics 101E
Now I realize that this doesn't solves your issue directly because you will be deploying release version and not debug one but I guess that there might be others stumbling upon this issue so this way you can at least continue developing, and if Microsoft doesn't use debug version than just maybe it isn't meant to be used.
So i'm doing this project for my Computer Programming Class (That's due tomorrow) and i'm basically done with everything. Our school has Visual Studio 2010, and I have Visual Studio 2017. However, when I open it, it asks me to change to ".NET Framework 4.6.1" as my computer doesn't have ".Net Framework =v4.0". When I do, I can edit the program, but I can't debug/compile the program, as it outputs this error:
The reference assemblies for framework ".NETFramework,Version=v4.6.1" were not found. To resolve this, instal the SDK or Targeting Pack for this framework version... Therefore your assembly may not be correctly trageted for the framework you intend.
However, when I tried to go online and install the v4.6.1, the installer said that I had already had a version of 4.6.1 or a more updated version on my computer. I don't understand why this is, and if there's another question like this it would be helpful if you could link it as a reply. Thanks.
The answer to your problem is directly in the error message. "To resolve this, instal the SDK or Targeting Pack for this framework version."
My advice: Download and install .NET 4.0 SDK on your computer.
You can try one of these links to get the SDK:
https://www.microsoft.com/en-us/download/details.aspx?id=8279
https://www.microsoft.com/en-us/download/details.aspx?id=8442
You can also try the multi-targeting pack.
https://www.microsoft.com/en-us/download/details.aspx?id=29052
Also, checkout:
You can use the setup verification tool to diagnose your .Net Framework here: .Net Framework Setup Verification Tool or Alternative Download.
Also check the .NET Framework Setup Verification Tool User’s Guide
If you do find problems with your .Net Framework, you can use the Repair Tool to fix it, it is designed to fix issues specifically concerning the .Net Framework as well as updates: Microsoft .NET Framework Repair Tool
Hope this will be useful, good luck.
For VS2017 to support .NET 4.0, you need to make sure you've installed the correct component:
The issue comes up when you install Visual studio 2012 on a machine without Visual studio 2010 installed previously (I think). I want to target .net 4.0, while building on Visual Studio 2012. I already have set up the machine without VisualStudo 2010. I end up with messages like:
*Warning 2 The primary reference "blablaLibraryproject" could not be resolved because it was built against the ".NETFramework,Version=v4.5" framework. This is a higher version than the currently targeted framework ".NETFramework,Version=v4.0". blablaExecutableproject*
The answering post here(Can a build server with .NET 4.5 installed successfully deploy a project targeting 4.0 to a server with only .NET 4.0 installed?) says:
You can correct this, but you need to add the 4.0 reference assemblies to your build server (so the compiler finds them), and not
just rely on the .NET 4.5 versions.
So how does one "add the 4.0 reference assemblies to your build server (so the compiler finds them)"?
They are already present on the machine. Just change the Target Framework setting of the project from 4.5 to 4.0
The problem discussed in that linked question is a pretty common one for programmers that try to setup a build server without paying for the VS license. Which goes pretty far, but is missing an otherwise freely available component, the multi-targeting packs for the .NET Framework versions.
Which is penny-wise but pound-foolish. They then make a fatal mistake, they add reference assemblies from c:\windows\microsoft.net instead. Like it was done in framework versions prior to .NET 4.0. This causes horrible to diagnose runtime exceptions when the built product is ran on a machine that only has 4.0 installed. The asker of the question was pretty lucky, he got a relatively easy to diagnose one. That however can be a lot worse, getting pretty bizarre TypeLoadExceptions for common framework types.
You don't have this problem, you installed VS so you already got the multi-targeting packs. The 4.0 version is available in C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.0. Both MSBuild and VS know how to find it there without your help. Just change the project setting to tell them that you want to target 4.0
In addition to Hans' answer, here is another possible reason for this:
My build server had Visual Studio installed, however, my project targeted .NET 4.0.3 and that specific target framework was missing on my build server. Therefore it silently defaulted to .NET 4.5.
I fixed this by changing the target framework of my project to .NET 4.