I'm trying develop a sample application with multi language files.
I use: Windows 7 64bit and Visual Studio 2012 Express.
I read a few tutorials on the web, and I created a sample app.
In my Debug directory I created folders for language files: 'en' and 'pl'
I created text resource files in these directories and in the main directory, so my file structure is:
lang.txt
lang.resouces
multilang.resources.dll
multilang.exe
-en
--lang.en.txt
--lang.en.resources
--multilang.resources.dll
-pl
--lang.pl.txt
--lang.pl.resources
--multilang.resources.dll
I wrote a .bat file to embed satellite assemblies do my app
resgen lang.txt
al.exe /t:lib /embed:lang.resources /culture:pl-PL /out:multilang.resources.dll
resgen en/lang.en.txt
al.exe /t:lib /embed:en/lang.en.resources,multilang.en.resources /culture:en /out:en/multilang.resources.dll
resgen pl/lang.pl.txt
al.exe /t:lib /embed:pl/lang.pl.resources,multilang.pl.resources /culture:pl /out:pl/multilang.resources.dll
In my application I use ResourceManager
_rm = new ResourceManager("multilang", Assembly.GetExecutingAssembly());
and the GetString method to obtain text
this._rm.GetString(stringFromRm);
It works fine when I compile my App in the .NET 4.5 Framework, but when I change the Target framework in Project properties to .NET 2.0 I always get this exception:
System.Resources.MissingManifestResourceException
My app must work on Windows XP, so it must work with earlier .NET Framework versions.
Could somebody tell me what I must change to run my app on .NET Framework 2.0 ?
When running resgen.exe or al.exe for an application that should run on .NET framework, you must make sure that generated assemblies can be read by .NET 2.0 runtime. Assembly format has been extended in .NET 4, so the 2.0 runtime is to able to load 4.0 assemblies.
So make sure that you're using both tools from C:\Windows\Microsoft.NET\Framework\v2.0.50727 and not from a newer framework version.
Related
I'm migrating from .NET Framework to .NET (Core).
I've just realized that .NET Core applications created by VS2022 always have a DLL:
And if I examine my EXE's details:
Why is the original filename set to the DLL? Can I change it to WinFormsApp2.exe?
With .NET Framework, no DLL was generated, and original filename was always set to the current EXE file. Can I reach this with .NET (Core) too?
.net core applications are cross-platforms which is why DLL is generated as part of the build process. DLL contains the compiled so you can run the app on platform which have .net core runtime.
you can change the setting in visual studio for a different DLL name.
on the other hand,.net framework applications are built as single executable file (EXE) that contains all the application's code and dependencies which is to be run only on windows OS.
It is normal to have .dll extension file because it is library which contains your code and allows to run program for multiple time in windows.
We have a project consisting of c++ core library and .NET wrappers (2.0 and 4.0) using Marshall. Build machine has Windows 8.1 OS.
C++ core and .NET 2.0 wrapper are built using MSVC 2005 and works perfect on other machines with lower windows versions.
.NET 4.0 wrapper is built using Microsoft SDK 7.1. Library works fine on build machine, but crashes on other machines (with .NET 4.0 installed) with following error:
Exception: System.MissingMethodException: Method not found: 'IntPtr System.Runtime.InteropServices.Marshal.GetFunctionPointerForDelegate(!!0)'.
It seems like wrapper was built using higher version of .NET and i have no idea how to solve this. As far as i understood there is no way to force using specific version of .NET 4.x while building though they are not backwards compatible.
You can specify the version of the .Net framework you want your app to use in the project properties window. Under the Application tab, select your preferred version under the Target framework dropdown. You can see more about targeting specific framework version on MSDN.
I managed to solve the problem. Somehow MSbuild used the best avilable toolset, though environment was configured to Windows SDK 7.1
While investigating the problem i finally found this article. So in order to build project i must configure environment to SDK and tell MSbuild to use toolset from this SDK.
So the solution is to call MSbuild with flag /p:PlatformToolset=Windows7.1SDK.
Thanks to everybody who was helping!
Because I don't use Visual Studio projects or MSBuild, I had to find out how to deal with this at the C# compiler's command line. It isn't that complicated, but there are some new concepts. The .NET assemblies in the same directory as csc.exe are "implementation assemblies". When you want to compile for a particular .NET version, you should use "reference assemblies", which are explained here: ILDasm, mscorlib and System.Runtime decompilation differences depending on the directory
You find reference assemblies under c:\program files (x86)\Reference Assemblies\Microsoft\Framework\.NET Framework. In there are directories for 3.5, 4.0, 4.5 and 4.5.1, on a machine with VS.2008 to VS.2013 installed. To make use of them, you need a command line like:
csc /target:library /noconfig /nostdlib+ /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NET Framework\v4.5\mscorlib.dll" MyLibSrc.cs
/noconfig tells the C# compiler to ignore csc.rsp, which provides it with a default list of assemblies to reference, which are the implementation assemblies you don't want.
/nostdlib+ tells the C# compiler not to use its default standard library.
/reference tells the C# compiler that it can use the library whose pathname follows. The one shown here is the standard library for .NET 4.5: the project I built this with only uses the standard library, so that was all I needed.
I am creating exe file of windows application using c# that creats a word application. I am targetting framework 2.0 and microsoft.interop.words ver 12. Problem is that client apllication having framework 4.0 and word 2010 installed have microsoft.interop.words ver 14.
Is ther any way I can embed above dll into exe file without using external tool or target to correct word dll version based on framework installed ??
In the settings area in you project under references you can reference the dll and set it to copy local, or you could limit you application to only use .NET 2.0
I have two versions of a same .net project dlls.One dll with .net 2.0 and one with .net 4.0 versions.This dll is referenced inside a .net demo project.When i run the exe generated by the Demo project in a Win7 OS or lower OS then exe should use .net 2.0 based dll.When i run the application in Windows 8 then it should use .net 4.0 based dll.How can i configure this using an application manifest file.IS there any other simpler methods.
Thanks,
I'd like to know which kind of files are stored in
C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.0\
Are those files meant for WPF/Silverlight?
And which installer install the files in that folder?
I'd like to know this because we have developed a winforms application with custom WPF controls. When we deploy the application on a bare system, the application crashes when these controls are used...
WPF is part of the .NET Framework since version 3.0
Silverlight is different from WPF and has a separate SDK download
Files located under Reference Assemblies folder, are usually installed by Visual studio when installing SDK and (in your case), are part of the Windows 7 and .NET 4 Framework SDK.
Winforms and WPF are quite different technologies. In short, Winforms are wrappers above Windows C++ MFC library and WPF are wrappers above DirectX library.
You should check the difference between Client profile and Full Framework because most of the time, your application should target the Client profile and in only few scenario, it should target the Full Framework. By the way, if you're using the .NET Framework 4.5 or above, Client profile has been discontinued. It simplifies the deployment process.
Check in the references properties in your C# project that the Copy Local is set to True. It will copy the referenced library in the output directory of the project.