I have a c# solution that accesses a c++ project through COM. The project has to be targeted to a specific processor, in this case x64. I am using the Windows installer to install the application.
The first problem I ran into was the c++ dll was not being registered properly when installed, and the program couldn't access it. I solved this by adding the c++ project to the solution.
For a while this worked, and everything installed properly, but then I started getting the following warning when I tried to build:
The target version of the .NET Framework in the project does not match the .NET Framework launch condition version '.NET Framework 3.5'. Update the version of the .NET Framework launch condition to match the target version of the.NET Framework in the Advanced Compile Options Dialog Box (VB) or the Application Page (C#, F#).
The setup would not install if I tried ignoring the warning. After some searching, I found that the c++ project was building in .NET 4.0, while my solution used .NET 3.5. I tried changing my solution to 4.0, but for some reason it stopped working, so I changed the c++ to 3.5.
This worked for a couple of builds, but then I began getting the following errors:
Error: LNK1104 cannot open file 'mfc90.dll'.
I added the file to the Additional Dependencies section, but then another link error occured (mfcs90.dll) and when adding that one, I got an x86 x64 conflict.
I'm not sure why these solutions worked for a while and then stopped, and I can't seem to find a resolution at any step that works. If anyone has seen anything similar to this, the insight would be appreciated.
In order to include the Microsoft runtime dlls, you should not simply include the dll in your application directory. This won't help when the dlls have various dependencies and you might run into different conflicts and versioning issues.
The way I would recommend installing the runtime dlls for you application is to include the official merge module in your MSI.
See the following link for your options to redistribute the runtime library:
http://msdn.microsoft.com/en-us/library/ms235316(v=vs.90).aspx
Related
I have made a project in VS2019. I have the same project in .NET Core and .NET Framework. I use a COM reference in my project. I would like to migrate these projects to Pi4.
A simple Hello World project (.NET Core) is running successfully on the Pi4 machine. However, when I try to run my project (.NET core or .NET Framework) it does not run on the Pi4. It says COM is not supported.
I tried to build the project using MSBuild in my Windows environment after looking for solutions in Google. I also see a similar error here. The error is: error : MSB4803: The task "ResolveComReference" is not supported on the .NET Core version of MSBuild. Please use the .NET Framework version of MSBuild.
The .NET Framework project also gives a similar error.
error MSB4028: The "ResolveComReference" task's outputs could not be retrieved from the "ResolvedFiles" parameter. Object does not match target type.
Does anyone have similar issues?
https://github.com/microsoft/msbuild/issues/3986
According to the above link. The employee of Microsoft is saying they can not give solution in the near future.
Set the Projects to x86 for them to build the Interop, the Interop created still could not be used in x64 runtimes.
Add the COM Reference to the Core project, Build it and you will get an Interop.YourCom in the bin/x86/core/debug folder.
Remove the COM reference, and re-add the Interop, it will be put into the Assemblies Dependencies, and MSBuild will work.
My MSB4803 was from a WIXInstaller project, for ADOX, and Microsoft.Office.Interop.Access.Dao
I stumbled upon this question many times and I experienced the same several times in different projects. It doesn't matter if it is Visual Studio 2019 or 2022 and the version of the build, unless you are working with the old MSBuild in a legacy environment, the COM Reference doesn't work. It is always safe to build it in the command line to understand if anything in the VS environment works. I don't truly understand why Microsoft let you make those references in the Visual Studio environment when they will not work nearly anywhere else.
There are some workarounds that might or might not work but if your code is already pointing at a COM library there is no much to do. You can install the NuGet package which is going to pass the build stage and remove the COM reference.
Install-Package Microsoft.Office.Interop.Excel -Version 15.0.4795.1001
The NuGet package has some differences at the types level that you will need to fix (the COM reference allows you to get specific types instead of objects from the cells values)
In any case, you will need the COM installed in the server, there is no workaround that issue.
I wouldn't say I like this error message or the link it shows on how to fix it, to be polite.... ;-);
I figured it out and thought as there are a lot of answers that are not helpful to share mine. What I did is update your command to force the use of msbuild.
dotnet msbuild -v:normal "FullOrRelativePathTo\MyProject.csproj" -p:Configuration=RELEASE
If that fails, try:
"C:\Program Files\Microsoft Visual Studio\2022\Enterprise\MSBuild\Current\Bin\msbuild.exe" "PathTo\Project.csproj" /p:Configuration=RELEASE
I know I'm late to the party, but here is a workaround working for me when I want to use Office Interop in .NET (Core):
Create an empty .net Console app (I'm using Rider and .NET 7)
Build it with the default MSBuild (17.0 in my case at the time of writing)
Add Interop references to the project file (I don't use Nuget, only generate these in a dummy .NET Framework project while adding COM references to Office libraries), eg.
<ItemGroup>
<COMReference Include="Excel">
<Guid>{00020813-0000-0000-C000-000000000046}</Guid>
<VersionMajor>1</VersionMajor>
<VersionMinor>9</VersionMinor>
<Lcid>0</Lcid>
<WrapperTool>tlbimp</WrapperTool>
<Isolated>False</Isolated>
<EmbedInteropTypes>True</EmbedInteropTypes>
</COMReference>
</ItemGroup>
Change the solution MSBuild version to 4.0
Try to build the solution, but the project will not even load properly due to an outdated MSBuild version
Revert the MSBuild version to the default one
Build the project - success! (this is the magic part, I can't explain it :P)
I have a solution with two projects (C# and U-SQL) to run in the Azure Data Factory. I have referenced microsoft.analytics to use some analytics functions.
After the VS update to 15.9.14 on July 9, 2019 the c# project was not building giving the error that the assembly is missing but it was not missing. If I clicked to the error it go away and recognize the assembly. Then I try to build again and same error appears.
So I check the dll and the version was the same as before update but after I opened it with dotPeek I saw that the assembly target framework was changed to 4.7.2.
My project is on 4.5 because of the official azure data factory documentation says that we can run projects only up to framework 4.5 so I can't upgrade to 4.7 or above.
You can see the difference of those dll.
Assemblies location:
C:\Program Files (x86)\Microsoft Visual
Studio\2017\Enterprise\Common7\IDE\PublicAssemblies
So to resolve the problem I froze those dll and added as external references to my project in order to compile and build it and it worked.
If I want to create a new U-SQL project I can only pick 4.7.2.
My question is, how I can run U-SQL projects and analytics assemblies on an framework that is still not supported in the azure data lake?
If the Data Lake now supports 4.7.2 why there is no documentation for it or at least something to let us know?
Is this an VS minor update with a bug?
So after some Microsoft tickets they don't know how to respond to this. They said to try run some methods that are only present in the 4.7.2 framework in the data lake.
So I tried those methods and the jobs didn't run for obvious reasons.
Conclusion:
VS migrated the U-SQL projects to 4.7.2 but we can't run custom c# code for this target framework in the Azure.
Data Lake Analytics runs only 4.5 as said in documentation.
For now our project will remain 4.5.
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 have downloaded published (code behind files are no there, combined with dll in bin folder) web application from Window Server 2008 where it is hosted, and open it with Visual Studio when I debug that application it shows following error:
"Could not load assembly because this assembly is built by a runtime newer than the currently loaded runtime"
I don't know how can I solve this problem and test application locally.
Please help me.
This errors happens when the DotNet framework you are using is of older version than the one used to build the assembly. You need to check which version of framework is used to build those assemblies and then use the same or higher to debug too.
I was getting this same error when running an installer for a Windows service, even when running the installer on the PC the installer was built on.
It turned out that although the Windows service project had been updated to .NET 4.5, the Setup project that was making the installer was still set to use .NET 2.0.
To check if the Setup project is using an older version of .NET than the project to be installed, in the Visual Studio Solution Explorer:
Expand the Setup project;
Under the Setup project, expand Detected Dependencies;
Under Detected Dependencies select Microsoft .NET Framework and check the Version property. Select the appropriate .NET version from the dropdown list;
Re-build the Setup project to create a new version of the installer.
This error can have a lot of other reasons, too. I had the same problem, and nothing helped until I stumbled across this:
TlbExp.exe error:This assembly is built by a runtime newer
I just ran into this issue when the assembly was built with a target framework of .NET 4, and v4.0.30319 was installed on the server, and other 4.0 apps were running successfully.
The problem arose because the app had originally been built targeting 2.0, and new 4.0 assemblies were pushed, but not the app.config file, which we generally update separately.
This means the supportedRuntime attribute was not updated in the config and caused the error. Adding the following to the app.config fixed our issue:
<startup><supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0"/></startup>
One the the assemblies reference in the project might be built using a newer version of .net, check version of every assembly reference and correct accordingly.
Also check the application pool that this web site is running as. It could be framework 2.0 default on some older windows servers. Change it to framework 4.0.
I an earlier thread I got some help to track down a deprecated .Net assembly reference and I was successfully able to port my project to build within Visual Studio 2010.
Is there any option to get this ReportViewer to work within Mono? Building the project with MonoDevelp 2.2.2 currently gives me similar errors:
Assembly "Microsoft.ReportViewer.Common Version=8.0.0 [...] not found
Assembly "Microsoft.ReportViewer.WinForms [...] not found
Thanks for all help :)
Try running all of the dependent assemblies through the Mono Migration Analyser. It currently targets Mono 2.6, but 2.8 has recently been released.
If the assemblies pass the tests in that then they'll work fine in Mono. If they don't pass the tests then there's a slim chance that they'll work, it just depends which functionality is used.