In order to create a C# CLR function, I need to create an assembly of my dll on a SQL Server 2008 SP3 machine. I have to build my project targeting .NET 2.0 as it appears that SQL Server 2008 only works with version 2.0. The problem is that my project has references to the other projects in the same solution which are all in version 4.0 and I cannot change them.
I did some searching online and it seems like you could create an application that targets the .NET Framework 4 referencing assemblies that targets .NET Framework 2.0 but not the other way around. (http://msdn.microsoft.com/en-us/library/ez524kew.aspx)
Is there a workaround of this? Any suggestions would be appreciated. Thanks.
Related
We recently need to upgrade our build server from Windows server 2008 to 2016. Because 08 is fading out
As we all know, Windows Server 2016 is installed with .NET Framework 4.6 and from https://learn.microsoft.com/en-us/dotnet/framework/install/on-windows-10
You can only have one version of the .NET Framework 4.x installed on your machine.
You cannot install an earlier version of the .NET Framework on your machine if a later version is already installed.
The case is, we have many projects using
.NET 4.0 with EF 4.4.0.0
.NET 4.5 with EF 5.0.0.0
And some classes such as System.ComponentModel.DataAnnotations.Schema.ColumnAttribute had moved from EF to .NET from EF 4.4.0.0 to .NET 4.5 along the upgrade.
Therefore, missing .NET 4.0 results in:
error CS0433: The type
'System.ComponentModel.DataAnnotations.Schema.ColumnAttribute' exists
in both ...\workspace\....\EntityFramework.dll and
...\Windows\Microsoft.NET\assembly\GAC_MSIL\System.ComponentModel.DataAnnotations\v4.0_4.0.0.0__31bf3856ad364e35\System.ComponentModel.DataAnnotations.dll'
because it trys to use .NET 4.5 with EF 4.4.0.0.
My question is: we don't have resources to ask QA teams to have a full test on every aspects of our applications, but we do need to use the new build server. Do you guys have any other idea / thought thats worth trying so that the it can build?
I'm certain there's probably a bunch of things going on here that I don't understand well enough, so forgive me if this is a stupid question or if there's obvious details missing.
I have a Visual Studio 2015 solution that I've upgraded from .NET 4.5.1 to .NET 4.7.1. The solution consists of a website (not web app) project, and several libraries. The libraries don't really have any dependencies (except eachother) and while they are targeting .NET 4.7.1, they don't use, need, or reference .NETStandard.Library.
When I compile one of the libraries in particular, it keeps copying a bunch of .NET 4.7.1 facade dlls into the website bin folder. Unfortunately, the website is a Kentico 11 application, and it keeps trying to load the System.IO.Compression.ZipFile facade, and chokes on it because it's a reference assembly, not a real assembly.
If I delete the .dll, everything runs fine... but I don't want to delete it every time or add a post-build event to delete it. That's just silly.
Can anyone help me understand what's going on here, and how to clean it up?
Kentico 11 can only target up to .NET 4.7 so in an attempt to fully support your .NET 4.7.1 libraries I believe it is copying in those additional facade DLLs. This is based on the .NET 4.7.1 release announcement, specifically this section:
BCL – .NET Standard 2.0 Support
.NET Framework 4.7.1 has built-in support for .NET Standard 2.0. .NET Framework 4.7.1 adds about 200 missing APIs that were part of .NET Standard 2.0 but not actually implemented by .NET Framework 4.6.1, 4.6.2 or 4.7. You can refer to details on .NET Standard on .NET Standard Microsoft docs.
Applications that target .NET Framework 4.6.1 through 4.7 must deploy additional .NET Standard 2.0 support files in order to consume .NET Standard 2.0 libraries. This situation occurred because the .NET Standard 2.0 spec was finalized after .NET Framework 4.6.1 was released. .NET Framework 4.7.1 is the first .NET Framework release after .NET Standard 2.0, enabling us to provide comprehensive .NET Standard 2.0 support.
https://blogs.msdn.microsoft.com/dotnet/2017/10/17/announcing-the-net-framework-4-7-1/
Reference that led me to this conclusion:
https://github.com/Particular/NServiceBus/issues/5047#issuecomment-339096350
Update:
I was unable to reproduce your issue in Visual Studio 2017 Version 15.6.2.
I installed a Kentico 11 website project targeting .NET 4.7. I then created a library project that targeted .NET 4.7.1. I added some dummy code to the project to make use of Sysetem.IO.Compression and System.Net.Http namespaces. I added a reference to the project from Kentico and ran a build. No facade DLLs where copied to the bin folder.
This post indicates the issue was fixed in Visual Studio version 15.6 https://github.com/dotnet/sdk/issues/1647#issuecomment-364999962
The additional files that get deployed to your bin folder are needed to support referencing and running .NET Standard 1.x and .NET Standard 2.0 libraries in your .NET Framework application.
We have documented this as a known issues with .NET Framework 4.7.1.
The presence of those additional files is not sufficient however. You also need to have binding redirects generated in order to ensure types correctly unify across libraries.
Visual Studio 15.6.3 (and later) have a change that will automatically generate those binding redirects for your application.
.NET Framework 4.7.2 addresses the issues that require those additional files to be deployed with your application. When targeting or running on .NET Framework 4.7.2 you won't have any additional files copied to your bin folder and no binding redirects will be automatically generated.
You can try .NET Framework 4.7.2 and see what's new by following the instructions here.
References to assemblies have their own properties. You can specify there if you want to copy the assembly to the build output directory. Maybe somewhere it is set to true. To check that go to Solution Explorer in Visual Studio and right click on the referenced assembly. Then click Properties and look for property named "Copy Local".
Does anybody know how I can run Awesomium.NET on .NET 3.5? Seems to only work on 4.0-4.5.1 right now.
According to this question, Awesomium 1.7 should be compatible with 3.5 by adding Awesomium.Mono to the project instead, but it seems like I'm not able to do that. When choosing 3.5 project in Visual Studio the Awesomium.Mono just disappears from the references list.
Well when I started using Awesomium web browser at version 1.7.0 the reference dll are builded using .net 4.0 version. You should try to look for an older version like 1.6.6 or 1.6.5 and check if they are builded using a older .net version. If you target your project to .net 4.0 you should not have any problem because at least windows XP with service pack 3 should have installed .net framework 4.0. But windows XP support has ended.
A quick solution (but not the best) is to target the project to the .net 4.0 and export all dll references to the build path. That should make no problems when deploying the app to your clients machine because the exe will reference to the build path.
Could you give me the reasons of why you are targeting .net 3.5 so I can understand a little more your issue with .net versions and try to think about another solution for you?
i am working on a dotnet C# web application which was initially created with VS 2003. My goal is to upgrade this application to Dotnet 4.0 without changing any functionaltiy. The solution has 9 projects (1 web + 8 Library projects). The Web project refers the 8 libraries in DLLs. To start off, I created a New project in VS2010 and added the all the Project files from the existing source code. Every time i add a project file to my solution, i was prompted with the Converison wizard and i completed the conversion wizard succesfully and now the solution works fine. After the conversion, i noticed that Except the "Web" project, other projects are converted to Dotnet 2.0 but not 4.0. My application runs without error if i run it locally using VS2010. My questions are
Why the Class libaray project did not upgrade to 4.0? Currently the
Web project is shows up as Dotnet 4.0 and Libaray projects shows up
as Dotnet 2.0.
Can i deploy the application to IIS 7.0 with the
Dotnet runtime of 4.0? Will the Dlls created in version 2.0 work if my application
uses Dotnet 4.0 runtime version?
Please help...
If your'e migrating now, why not move directly to Visual Studio 2012, instead of 2010?
Anyway, what you can do is open the project properties in each of your projects, and change the target framework to the .NET framework 4.0.
Then if you get any compilation error you can probably easily solve it individually. This should be relatively easy if your projects are not too big.
As for your specific questions:
The automatic conversion would only change the format of the solution/projects to be compatible with the new version Visual Studio. It shouldn't change the target framework but you can change that yourself.
Yes, assemblies targeting .NET 2.0 can be loaded and used from assemblies targeting .NET 4.0.
1) Upgrading the solution/projects file only upgrades it's format so you can open it in VS 2010. It will usually leave the targeted .NET setting at the previous value. These are two seperate things. The wonderful thing about VS 2010 is it let's you target whatever version of .NET you desire, so no longer do you need multiple version of VS installed to support differnt .NET versions. It didn't change the targetted .NET version because it leaves it up to you. You can change it under the project settings and recompile your library projects to regenerate the DLLs
2) You will need an application pool for .NET 4. .NET is backwards compatible in that a .NET 2.0 app can run on a machine with .net 4 installed. However, the application pool for 2.0 applications must be separate from 4.0 apps. So it's just a matter of putting the app under the right app pool.
I am developing using 3.0 and VS 2008.
The problem is my build server does not have 3.5 installed and therefore I cant build the solution as MSBuild for 2.0 will not support the VS 2008 solution file.
There is no easy answer to this besides downgrading to VS 2005.
Any ideas folks?
VS2008 supports C# 3 - you may be using C# 3-specific features while still targeting .NET 2.0.
Is there a strong reason why you can't install .NET 3.5 on the build server? That would be my preferred solution, rather than regressing the version of VS you use.
You could probably automate downgrading the solution/project files - if you're not doing anything complicated, it'll just be a matter of changing version numbers - but it's not great to have the build server using a different compiler to the developers, IMO.
Since you have VS2008 projects and solutions you will need to install .NET 3.5 on you build server. Since you can still target .NET 3.0 or .NET 3.5 having .NET 3.5 installed on your build machine should not have any impact on the target environment.
Is it not possible to include the different versions without 'installing' them? In the repository can you add versioned .NET and point the build script to the version(I'm thinking like a submodule in Git) you want for that project? So instead of installing .NET 3.0, 3.5, 4.0, etc include the libraries?