I have a VS2008 Professional solution that I tried to convert to VS2010 Professional (RTM from MSDN download) today and I am experiencing some problems with some unmanaged and managed C++ DLLs that are referenced by a C# application.
The C# application is set to target .NET 3.5 (as it was in the VS2008 version) but when I try and compile it I get a lot of warnings like:
The primary reference "xxxx.dll" could
not be resolved because it had an
indirect dependency on the .NET
Framework assembly "(various assembly
names)", Version 4.0.0.0 ... which has
a higher version "4.0.0.0" than the
version "3.5.0.0" in the current
target framework
and ultimately I get a failure to build.
From this I understand that it is a mismatch in .Net framework version. So I look at the properties of the unmanaged C++ DLL project and under "Common Properties->Framework and References" I can see "Targeted framework: .NetFramework, Version=v4.0"
So I go WTF!?!?!?, why does a pure C++ DLL now target a .Net framework when it sure as hell didn't in the VS2008 version. I then added on to that exclamation as there appears to be no way to change this. I also look at the managed C++ and see the same thing: targeting .Net version=v4.0 and again no way to change this at all.
In the C++ General properties there is an entry for "Common language runtime support" and I have set this to "No common language run time support" but that hasn't seem to have done anything.
So I have two questions:
Why has my pure C++ DLL now been tagged as targeting a .Net framework?
How can I change/remove this targeting?
Solution
As per Hans' reply and the link he supplied I now see that I have 3 choices:
Stay at VS2008 and everything works
Keep both VS2008 SP1 and VS2010
installed so that I can have .Net
3.5 c# applications and c++ managed code as per the link supplied by Hans.
Move everything to VS2010 and move
to a minimum of .Net 4.0 for all my
c# apps
I am really annoyed to have to make that choice as MS has deliberately chosen to break functionality when moving from VS2008 to VS2010. This is not the sort of behavior I expected. I was expecting to convert the project and have it compile with no issues in the same manner that moving from VS2005 to VS2008 worked.
Fortunately I do have a need to go to .Net 4.0, but I just wasn't expecting to have to do it so soon.
Update
I decided to move to .Net 4 framework and encountered problems with referencing managed c++ projects from c# projects. I was getting errors like the following when trying to add the reference to the c++ managed code project
A reference to 'myproj' could not be
added. An Assembly must have a 'dll'
or 'exe' extension in order to be
referenced.
Google lead me down the path to "cli c project cannot be referenced from c project allowing only assembly dll" which turned up that there was an extraneous "\" in the output path of the managed c++ project. The original VS2008 output path was specified as
$(SolutionDir)\$(ProjectName)\$(Configuration)\
But in the VS2010 project the SolutionDir macro has a trailing "\" (or the VS2008 version didn't care about it) giving a path like
c:\projects\thisproject\solution\\projectname\configuration\
And VS2010 barfed over that path when trying to add a reference to the managed c++ code. My solution was to change the output path to be
$(SolutionDir)$(ProjectName)\$(Configuration)\
And now I am (sort of) happy
Keep your eyes on the ball, the warning you get is for a managed C++ assembly. And the platform target setting for an unmanaged DLL is of no consequence, it won't use any .NET references while being built.
Yes, they could not make the platform target setting editable in the C++ IDE, the VS2008 tool chain is required to build C++/CLI assemblies for 3.5. This blog post explains the workaround. You can upvote this feedback article if you're unhappy with that.
Related
I need to use the NuGet package OPCFoundation.NetStandard.Opc.Ua in a .NET Framework 4.7.x class library.
So far my class library was .NET Framework 4.7.0. It worked OK, although the OPCFoundateion.NetStandard.Opc.Ua package (.NET Standard 2.0) generated a HUGE bunch of shim system DLLs in the bin folder. Not good at all, but it worked.
Because I found all those dozens of shim dll's very annoying I made some research. According to various articles I learned that all those DLLs should go away once I upgrade my class library to version 4.7.2.
Well so I did, but things only got worse.
If you try this:
Create a brand new solution (VS2017, fully updated)
Create a blank 4.7.2 class library
Import the OPCFoundation.NetStandard.Opc.Ua package into the class library
the following happens:
Still 83 system.* (and other) shim packages are being downoaded,
installed and stored in the Packages folder
25 warnings pop up, saying: "The referenced component
'System.xxxx.xxxx' could not be found"
If I ignore those warnings and try to use the package nevertheless, I get runtime exceptions saying that various DLLs are missing.
What is going on? Why doesn't it work with 4.7.2 while it works with 4.7.0?
I urge you to try it out for yourself, it is very, very easy to reproduce.
I use packages.config for NuGet handling, mainly because I cannot get our TeamCity build server build the project if I use packageReferences.
.net 4.7.2 library referencing standard 2.0 NuGetPackage does not work
This is a known issue Issues with .NET Standard 2.0 with .NET Framework & NuGet, those warning messages were added from .net framework 4.7.1 by MS to remind the user to know that this issue exists. That is the reason why it does not work with 4.7.2 while it works with 4.7.
But the warnings are innocuous and merely present in the IDE, but may be annoying.
To resolve those warnings, you can remove those System.* references from your project, since you can not use packageReferences.
See Adding .NET Standard libraries to 4.7.1 lib adds loads of references, some broken for some more info:
Hope this helps.
We have a Visual Studio solution with about 90 projects. Most of them are built to DLL files, some are written in C++, others in C#. The projects communicate with each other via COM. We use tlbexp to generate TLB files of some C# projects (the ones that are referenced in C++ projects). And we use tlbimp to generate interop DLLs of the C++ projects. I did not completely dig into the topic, but I think, the interop files just define the interfaces of the C++ classes, to make them usable from other projects is that right?
Now, the question is the following: In order to upgrade the entire solution to Visual Studio 2015 and let it compile against .NET 4.6.1, I inspected the resulting assemblies using dotPeek by JetBrains. I can see, that all the C# projects are correctly using .NET 4.6.1, the C++ DLLs themselves are native and do not reference any .NET. Now, what surprised me was the fact, that dotPeek told me, the interop DLLs (which resulted from the C++ projects), were referencing .NET 4.0.
After a "wonderful" day of trying to make them reference .NET 4.6.1 and lots of research, I finally did not find any way to make the interops reference .NET 4.6.1. Is that even possible? My current guess is, that all interop DLLs generated like this reference just the basic .NET 4.0, just because it uses the same CLR as .NET 4.6.1.
Is that right? It should be possible to execute the assemblies on any system that has .NET Framework 4.6.1 installed, shouldn't it?
You are getting bad info from dotPeek. It doesn't tell you how it figured out what .NET version is targeted. It can be specific on a .NET assembly that's generated by a compiler. Because it automatically inserts a [TargetFramework] attribute into the assembly, it states what version of .NET you selected when you built the project.
But an interop assembly does not specify a .NET version, primarily because it isn't generated by a compiler. Note how you never specified a version when you ran Tlbimp.exe. And can't. All that dotPeek can figure out is that it targets .NET 4, cued by the metadata format. No way it can be more specific.
And it does not matter, since the interop library does not use .NET Framework features. The only point of the library is that your program can use the COM component features. So the version number that dotPeek reports just doesn't matter; any .NET 4.x framework can use the library.
You don't have a real problem.
I have an executable I made using a CLI console application with Visual Basic 2010. I can run the program completely fine from my developer machine.
However, when I copy the executable over to another machine, re-boot to a pre-installation environment and run the executable again, nothing happens at all. There are no errors shown or anything.
My guess is the executable can't run without certain dependencies that aren't loaded at this environment, but I need it to work in a PE.
Any ideas on whats going on?
First of all, since the question is tagged "c++" and you mention C++/CLI several times, I assume that "Visual Basic 2010" is a typo for "Visual Studio 2010". But either way, whether you've written the application in Visual Basic (VB.NET) or C++/CLI, the problem is exactly the same.
My guess is the executable can't run without certain dependencies that aren't loaded at this environment, but I need it to work in a PE.
That's exactly correct. You've written an application that targets the .NET Framework. Somewhat like Java applications requiring a JVM, .NET applications require that the .NET Framework be installed in order to run (or a compatible alternative implementation, like Mono). Unfortunately, Windows PE does not support the .NET Framework.
Note that it is irrelevant whether you've written a WinForms, WPF, or Console application. Although they present their UI in very different ways, they all depend on the .NET Framework being installed.
You will need to (re-)write the application in a different programming language, one that generates native code without any dependencies on the .NET Framework. C and C++ are popular choices. If you choose to use C++, make sure that you create what Visual Studio calls a "Win32" project. This is one that targets the underlying operating system APIs directly (i.e. a native application) and does not have a dependency on the .NET Framework. Stay away from anything that has ".NET" or "CLR" in its description.
I don't really have a full comprehension of when an application is using .NET or not... I am just used to Linux C/C++ development. I hate Microsoft shit
It uses .NET whenever you use the .NET Framework libraries/classes in your code. I'm not really sure why this is so difficult to understand. The same problem could easily exist on Linux if you were using a third-party library that was not available in certain environments for whatever reason. This is not Microsoft's problem, it's an issue of using the wrong tools for the job. The .NET Framework is an object-oriented wrapper around the native APIs that makes it much easier for people to get up and running writing programs for Windows. But if you're "used to Linux C/C++ development", you should have little trouble writing a simple console application that targets the native APIs directly without using .NET.
If your hatred for "Microsoft shit" has turned into an allergy, you can avoid Visual Studio entirely and download MinGW, which is a Windows port of the GCC compiler you're probably used to. Combined with your favorite Windows port of Vi, you're working in an environment very similar to the one you're used to. And since GCC doesn't support C++/CLI or the .NET Framework, you won't have to worry about getting stuck picking the wrong option.
The .Net framework has been supported as an optional package install during your PE build process for the past couple versions of WinPE. I write code in C# that I run in WinPE everyday. I have yet to find a good way to debug in a manner where I can walk through break points, etc... though. My best option has just been a lot of logging and a global Exception catch around my main entry point that will write out a full stack dump. You can attach to your app as a remote process in a VM running WinPE, but if you need to catch something early in the execution you'll have a difficult time.
I have a project that requires writing a code for small executable file. I used visual C++ express 2010 IDE to create this file. After I finished writing the code, I tried to copy it to a couple of different PCs. It gives me an error message every time I clicking on this file to execute it. The message states that I have to install (.NET framework). I watched a couple videos on YouTube explaining how overcome this problem by changing the runtime library from multi-threaded Debug DLL (/MDd) to multi-threaded Debug (/Mtd). However; the IDE can’t debug the C++ code because when I create my project by using CLR template!
Is there any way to solve this problem? Can I create a similar program that not requires any further downloading once I using on different PC?
Is learning a different language like JAVA or C# will help creating small programs (like my program) that run on most Window platform machine?
Just use Qt - it runs on Windows, Linux, MacOS, support for Android and iOS is scheduled for this year, plus it supports embedded platforms and some of the more obscure mobile platforms. Also, support for Windows RT was just kickstarted. A complete library with tons of functionality, good documentation and lots of educational resources. It provides tons of tools, from implicitly shared containers through threading, signals and slots, 2D and 3D graphics, widgets, multimedia, sensors... and whatnot...
You can even develop commercial applications under the LGPL license.
Also comes with a pretty good IDE - Qt Creator.
You can develop standard C++ applications or use QML, which is a JavaScript like language for markup and scripting, which is used to build applications from C++ implemented components. You can also extend QML. It is much faster to develop with QML and you still get the advantages of platform native binary under the hood.
Note that you will still need to either ship a few DLLs with your application. Unless of course you use a static build, which requires you to either have your application open source, or purchase a commercial license... which doesn't come cheap...
But still, a few MB of DLLs are far better than the entire .NET framework. A static build will produce executables about 8-9 MB with no external dependencies.
Stick with the C++ standard, avoid Microsoft extensions (managed code), and call only POSIX functions of your OS, then you should be able to write portable programs.
You seem to have created a Managed C++ Project. Instead create an empty Win32 C++ project and then add in your .cpp/.h files. This will limit you to the default libraries available on all PCs with the C++ runtime. If you want to remove that dependency too then statically compile in the runtime using the /MT option. Details # http://msdn.microsoft.com/en-us/library/2kzt1wy3(v=vs.71).aspx
As you move ahead you would need to be conscious of what libraries you take dependencies on and what versions of the OS are those libraries available on or if you need to package them with your bits.
Both Java and C# will help making portable programs. Usually, people will have to install runtime environments for executables written in these two languages, however. These days, C++ is more portable than ever. You can easily run C++ executables in your browser:
https://github.com/kripken/emscripten
http://code.google.com/p/nativeclient/
This makes many of the reasons why Java and C# came about irrelevant.
Open standards like OpenGL also make portable GUI programming easier than ever. Try Qt, if you want to write a simple GUI in C++.
Note: It is possible to run C++ program in any computer without installing anything if you haven't use .NET framework. In your case, there can be two reasons to trigger error in target computer.
New computer doesn't have required run-time assembles.
New computer doesn't have required .NET framework installed.
..........................................
So what to do:
Before start your program you have to design weather are you going to use .NET framework support or not. If you use .NET framework when you develop your program, then you much install same or higher .NET framework in target computer.
If you no need to use .NET component then your target computer should only containing run-time assemblies.
How to get rid of .net framework
right click on the project in solution -> properties -> General -> Common language run time support -> select "No common language run time support".
..........................................
Then what you need is only relevant run-time assemblies be in target computer.
How can run-time assemblies be in new computer:
There are two ways:
Install suitable C++ disputable environment in target computer(if you use VS2008 SP1, C++ RD package should be this. Please consider the solution build architecture also (32 bit/64 bit) before download ).
Deploy run-time assemblies with your solution package. (I like this because user no need to install any third party components)
..........................................
How Deploy assemblies with my project:
for this your all DLL, LIB, EXE should use same run time version.(if not, you face troubling to redirect assemblies by 'manifest' files ).
How to check the run-time version.
open DLL,EXE by visual studio (open->file) -> expand RT_MANIFEST-> double click the file under it ->then assembly dependency details will open. -> copy the data in right column and paste to note pad.
You will see this kind of line there. and ther is the version run-time assemblies your specific DLL or EXE use.
assemblyIdentity type="win32" name="Microsoft.VC90.CRT" version="9.0.21022.8" processorArchitecture="x86".....
After identifying the version of run-time assemblies follow this tutorial and try to run in fresh installed computer.
At last: If you think this bla.. bla.. is so complex and your program is very simple, then you can consider about "run time assemblies statically linking" (try Google). But personally I don't like this method.
good luck!
Native exe!
that means my program can run easily without any requirement?
even if I use .net classes?
You know I want to write a program that is so light and I don't like to use C# or any other .net programing language because all of them need .net-framework 4.5.
Just think a 2.5 MB programm needs a +250 MB .netframework.
New Update - 12/01/2016:
It's almost 4 years ago when I asked this question. As you know Dotnet Native is announced. It's an interesting feature which compile IL into native code.
Compiling Apps with .NET Native
.NET Native is a precompilation technology for building and deploying
Windows apps that is included with Visual Studio 2015. It
automatically compiles the release version of apps that are written in
managed code (C# or Visual Basic) and that target the .NET Framework
and Windows 10 to native code. Typically, apps that target the .NET
Framework are compiled to intermediate language (IL). At run time, the
just-in-time (JIT) compiler translates the IL to native code. In
contrast, .NET Native compiles Windows apps directly to native code.
For developers, this means:
Your apps will provide the superior performance of native code.
You can continue to program in C# or Visual Basic.
You can continue to take advantage of the resources provided by the .NET Framework, including its class library, automatic memory
management and garbage collection, and exception handling.
Last I checked none of the .NET frameworks were 250+ MB! Yes, the offline installer for .NET Framework 3.5 SP1 is 231MB but it contains x86 and x64 versions of .NET 2, 3 and 3.5 sp1.
You should read this http://www.smallestdotnet.com for details on sizes of various versions of the installers.
Now on to your question:
Yes, It is a little annoying to have your clients install a big framework, even 20-40MB does get annoying. With .NET, the advantage is the ease of programming (In my opionion) compared to other Native options.
Your native options are:
MFC - You need only the VS runtimes installed, which is 1-2MB and is usually installed on newer pcs. Also, you can ship your application with the MFC libraries packaged into a dll which is again <2MB
The trade of here is you need to program in C++, the libraries overall are a very thin layer over the native libraries. and people have had harsh opinions about MFC. I've barely just tried it.
Win32 API - This is going all bare bones, and quite difficult, you could use C or C++ but you'd really have to know a lot about the Win32 API and how windows itself works (Stuff like windows messages, hwnds etc) Its not fun, believe me. But during deployment you would not need any external libraries.
There are tons more options, see here:
Native Windows Application Development Options
https://stackoverflow.com/questions/2711599/what-programming-language-should-i-use-to-create-small-native-windows-applicatio
Here are some links on MFC that might help:
Want to learn Windows Programming,some suggestions?
How do I decide whether to use ATL, MFC, Win32 or CLR for a new C++ project?
C++ MFC vs .NET?
https://stackoverflow.com/questions/557114/stick-with-mfc-or-go-to-net
you are able to create native exe by using c++ Win 32 projects.
Alas, nearly everything requires a download runtime library and even if you have one installed, you'll need to download updates for them almost continually. Even Microsoft C++ apps nowadays come with security updates that have to be installed if you've compiled your app with them.
But.. there is a solution of sorts. If you use C++, it has a feature where only the things you use are compiled into the final app. Normally, this would require linking with all the library dlls, but if you statically link with the library, you will end up with a single .exe that is as small as can be, and you will not need any dlls (as all the code contained in the library will be compiled into the .exe).
The benefits are debatable compared to dlls, but as MS has pretty much broken the idea of shared dlls in .NET (ie, you practically have to put all the shared dlls in the same directory as your running app, giving you a nightmare in maintenance if you have these shared dlls spread around all your apps) then there's not much of a difference anymore. Static linking is getting a little bit of a comeback and sounds like its what you want.
For modern C++ development, you'll probably want to take a look at Qt instead of MFC. Its a lot nicer to use and is cross-platform so you can run Qt apps on your Android or Linux platforms as well as Windows.