I can't find a template for a linq to sql class in .net 2.0 project, based on what i know you can work with linq in .NET 2.0 as long as you have 3.5 in your development machine and ship system.core.dll with your application?
so based on that how can I add a Linq to Sql model to my project when "Linq to Sql Classes" template is missing from the add new item window?
Edit:
Just to clear things up, This is a server application and the server will have .net 3.5 SP1. the only issues is that we can not upgrade the project to .net 3.5 at the moment.
If you ship System.Core with your application, it won't pick up future security fixes and won't have the optimized build installed (MS internally uses and profiling NGEN for distributed framework libraries). Either require .NET 3.5, avoid using Linq, or implement your own extensions for a custom Linq provider.
The approach you are taking is dangerous and will almost certainly lead to errors on your deployment machine.
The 3.5 framework, and specifically System.Core.dll, rely on the CLR being at least 2.0 SP1. There are several bugs in CLR 2.0 that are exposed by the use of the expression tree API and other code which Linq2Sql relies upon.
If you ship System.Core.dll only the clients are not guaranteed to have, and likely won't have, the CLR service pack. Hitting any of these bugs will result in hard to understand failures in your application.
You may get lucky for awhile but this is an untested and unsupported scenario.
I highly advise you to not do this
Try adding a reference to System.Core
http://iformattable.blogspot.com/2008/05/using-linq-from-net-20.html
I figured it out, All you have to do is add a new text file to the project, but change the extension from .txt to .dbml and it'll automatically be picked up by visual studio. it will even generate all the code behind for you.
Related
I currently have a utilities library built as .NET Framework 4.6.1 and referenced by various .NET Framework applications.
I now want to create a new .NET Core application and therefore I want to convert the utilities library to .NET Standard 2.0 so that it can be used by applications of both types.
If I simply open the source code for the library, change the target to .NET Standard 2.0 and rebuild it (assuming that it does only use APIs available in .NET Standard), can I just drop the new assembly in to replace the existing one and should the existing applications still work? Or would the applications need to be rebuilt against the new version?
And the more general related question is, what are the differences in the metadata produced for a .NET Standard DLL compared to a .NET Framework one, and how/if do they affect the assembly resolver?
(to pre-empt the comment "why not just try it and see", I want to know if this is a supported scenario, not just whether technically it might work for me)
.Net Standard is a compatible cross-section between (but not limited to) .Net Framework and .Net Core
Think of it like this
Or, one of the more standard propaganda pictures
There are lot of things in .Net Framework that just doesn't make a lot of sense in .Net Core. Windows specific things for instance.
However, what you can do is use The .NET Portability Analyzer to work out any glaring compatibility problems
Want to make your libraries multi-platform? Want to see how much work
is required to make your application compatible with other .NET
implementations and profiles, including .NET Core, .NET Standard, UWP,
and Xamarin for iOS, Android, and Mac? The .NET Portability Analyzer
is a tool that provides you with a detailed report on how flexible
your program is across .NET implementations by analyzing assemblies.
The Portability Analyzer is offered as a Visual Studio Extension and
as a console app.
And here is another picture (of the tool), because it makes my post look detailed
To answer your question
If I simply open the source code for the library, change the target to
.NET Standard 2.0 and rebuild it, can I just drop the new assembly in
to replace the existing one and should the existing applications still
work? Or would the applications need to be rebuilt against the new
version?
Needs to be rebuilt as far as i know, try it see what happens and let us know.
There are so many things that could make this not work.
And the more general related question is, what are the differences in
the metadata produced for a .NET Standard DLL compared to a .NET
Framework one, and how/if do they affect the assembly resolver?
Not entirely sure what you mean, however it will resolve just the same when rebuilt.
(to pre-empt the comment "why not just try it and see", I want to know
if this is a supported scenario, not just whether technically it might
work for me)
Just replacing the assembly is not supported as far as i know or could research. However maybe someone else has more information here.
I've been reading and trying to use NUnit, and so far the books/articles I am reading say that in the bin folder of NUnit, there should be nunit.framework.dll, which I need to reference in my project.
But the strange thing is that there is no nunit.framework.dll, but there are two folders: net-1.1 and net-2.0.
I use neither, I am working in VS 2010 with .NET 4.0.
Is NUnit deprecated?
Why would they only have two folders for old versions of .NET?
To start off, NUnit is in no way deprecated and has become de facto primary unit testing framework for .NET.
However, as a testing framework, it doesn't involve compiling expressions, doesn't use LINQ or dynamic language constructs, and in its current implementation relies on feature found even in .NET 1.0, such as attributes.
However, with the release of .NET 2.0, a new CLR was shipped. Old .NET 1.1 assemblies had to be “remapped” in the application configuration file in order to be picked up by the new CLR, and people would get issues with running their .NET 2.0 applications with a library compiled for .NET 1.1.
When .NET 3.0 and .NET 3.5 came out, they didn't carry a new CLR along. Both of them still use .NET 2.0 CLR and only add some libraries (WPF, WCF) and language features (such as LINQ) with them. Because these releases don't bring changes to CLR, there is absolutely no sense in distributing separate library versions for them, as the binaries would stay exactly the same, referencing version of mscorlib found in .NET 2.0.
I'm not sure about .NET 4.0 and if it requires entry in App.config to properly load .NET 2.0-compiled NUnit library so I am open to comments on this.
There's a quote from NUnit blog explaining separate 1.1 and 2.0 packaging:
So, if it’s possible to run the
original, built-with-net-1.1 version
of NUnit under any version of the CLR,
why do we need a separate .Net 2.0
version? Strictly speaking, we don’t.
But it’s convenient for a few reasons:
Folks seem to have an inordinate amount of trouble getting NUnit to run
under the proper framework version.
Having a special version will make
their lives a bit easier, not to
mention mine, since I have to answer
all the questions.
Eventually, we will need a separate version. It’s inevitable that people
will begin to use 2.0-only features in
their tests. Imagine an Assert on a
nullable value. Or a generic
TestFixture class. We’ll be able to
deal with some of those things from an
NUnit built with .Net 1.1, but many of
them will either require .Net 2.0 or
be much simpler to implement with .Net
2.0.
For now, the .Net 2.0 builds are
identical in features to the .Net 1.1
builds. We have reflected this in not
changing the version numbering for
now. Those using one or the other
framework version exclusively can
download a copy of NUnit built to use
that version without missing out on
any features. Those using both
versions have the choice of installing
both versions side by side – just be
careful which one you reference – or
using the command-line /framework
option to select the correct version
on the fly.
(highlighting is mine)
However, it was posted a long time ago (November 2006) so probably by now the versions do differ.
The net-2.0 version was built using .NET 2.0, but it will run successfully under .NET 4.0 (it's got entries in its .exe.config file to enable this). And it will successfully run tests that were built with .NET 4.0.
I agree that it would be less confusing if they provided binaries that were more obviously current, but there's no technical need for them. Use the net-2.0 folder; it should work for you.
Goto http://nuget.org/ and install NuGet. Then follow the instructions on how to add a NuGet package to your project. Then search for NUnit and it will automatically import the correct dll for your project.
By the way, with a .NET 4.0, you can use any dll above 2.0 so you can use NUnit .NET 2.0 assembly with your project. It will automatically be loaded and run with CLR v4 along with your own assemblies so no performance penalty there.
How can I check what objects, tools, variables, anything... are used from .NET 2.0 in a C# application.
How can I get a C# application run without .NET 2.0 ?
UPDATE:
sorry, I didn't clarify enought. Here's my situation: I have developed a pretty simple application in C#: embeded browser which displayes static webpages with an option of searching inside of these html pages. I'm using simple textbox, buttons components for this.
The application will be distribuited for people wich have very old PCs, even with windows 95. I would like the app to be runable on it, or at least on win 98, without telling the people to install .NET 2.0, as the users don;t really have PC usage skills :) .
I'm using a dataGridView as well.
You can have a look at this : http://www.remotesoft.com/linker/
"The mini-deployment tool puts
together the minimum set of CLR
runtime files and dependent assemblies
that can be simply copied to a single
folder on a target machine, and your
application runs as if the whole
framework is installed. Since the
installation is isolated into a single
folder, there will be no conflicts
with future .NET installation. When
linking is used for the dependent
assemblies, it will further reduce the
file size."
You may need to clarify a bit more.. do you want the app to run without .Net at all? Or you want it to run in .Net 3.5 without .net 2.0 bits?
If its the latter, then simply don't reference assemblies that are compiled in .net 2.0 (check the properties on the reference you have added). If its the former, then its really not feasable. Yes its possible, but it means deploying parts of the framework with your app, but then, you'd be deploying all the bits, including the 2.0 bits.
Your're question really needs more information though, it doesn't make much sense currently. Sorry. =)
To make sure it runs without .NET 2.0, compile it with the .NET 1.1 compiler.
But this seems like not a good idea. I'd recommend revisiting your requirements.
Win98 wasn't shipped with .NET. Using .NET v1.1 won't get you much more platform penetration than .NET 2.0, if any.
IT looks like windows 98 supports the .net framework. See this answer for details:
OS Compatibility for various .NET Framework versions
You cannot run a .NET application (i.e., that uses the CLR) if you haven't installed the corresponding .NET Framework binaries (i.e., that contains the CLR) directly or indirectly.
Period.
Is it possible to force the C# compiler to pull all the referenced calls out of the framework and pack them into dlls or even a single executable?
I like writing quick 'one-off' applications with C#, however I don't want to have to install the whole framework on the target machine once it's ready to go.
You ask a loaded question. C# is merely a language and does not require the .NET Framework. The process of compiling it requires a compiler, which may or may not itself take a dependency on the .NET Framework (Microsoft's C# compiler does not -- it is written in native code). Your program will need to reference some assembly where types, classes, and methods can be found for your use. You can remove system.dll and mscorlib.dll from your references list and reference your own assemblies. So you can avoid dependencies on the .NET Framework if you really work at it. But in the end, unless you have a C# compiler that compiles programs to native code you still have a dependency on the CLR.
That's a very technical way of saying... almost nothing. But it answers your question. :) More practically useful however is how to get your C# programs to run with a minimum of dependencies. mkbundle from mono will actually let you compile it all into an .exe with virtually no dependencies.
But if you want to stick with the Microsoft .NET Framework, you can achieve a much lighter footprint and faster install of the dependencies you commonly need by using the Client profile of .NET 3.5 SP1. You can read about it here:
http://msdn.microsoft.com/en-us/library/cc656912.aspx
Look at mkbundle using Mono.
It is now possible to compile C# to native code using Microsoft .NET Native:
https://msdn.microsoft.com/en-us/library/dn584397(v=vs.110).aspx
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.
...
For users of your apps, .NET Native offers these advantages:
•Fast execution times
•Consistently speedy startup times
•Low deployment and update costs
•Optimized app memory usage
This only works with Visual Studio .NET 2015.
Take a look at the .NET client profile.
This will allow you to package a minimum install on the client machine.. which will later be updated by windows update to the full framework.
This depends, of course, on your app only using libraries that are contained in the client profile ...
Some info here: http://blogs.windowsclient.net/trickster92/archive/2008/05/21/introducing-the-net-framework-client-profile.aspx
It's said it is possible, using 3rd-party tools such as http://www.remotesoft.com/linker/
Not possible. Your "compiled" C# application is a language which the .Net CLR interprets (should have said JITed, Reads the IL, compiles to native code, and then invokes the compiled native code) at runtime.
FYI .net 2.0 is a standard install on xp SP2 and vista, so you won't be paying that much of a penalty.
You could look into mono, but this still involves running some kind of framework on your target machine.
This dependency which unfortunately frequently breaks or is missing in the real world is a big reason why C# has not had a wider adoption. On the flip side most development does have dependencies.. look at C++ & Java for example.
I don't think we will really get away from these dependency issues anytime soon, so I recommend that if you want to use C#, that you make a wrapper for installation which checks for the .net framework version dependency you need, and if missing notify the user that they need this to run your app.
Some C# features are bound to interfaces of the .NET framework.
For example:
yield return requires the IEnumerable interface
using (x) {} requires the IDisposable interface
I can't seem to get my application up and running on my dev server and I'm not sure why.
I have compiled my code in VS 2008 with a target framework of 3.5. I am using 3.5 mainly because I have implemented LINQ rather extensively. Compiling and runs local without any problems.
The hang up is that my server only has the 2.0 .Net framework and upgrading to 3.5 is apparently not going to happen.
I was under the impression after doing some research that as long as I was trying to execute compiled code the server would not need 3.5 installed.
Today I am trying to publish to the server and I can't get past this error in my WEB.CONFIG
Configuration Error
Parser Error Message: Child nodes not allowed.
providerOption name="CompilerVersion" value="v3.5"/
EDIT ADD ON QUESTION:
I have seen some posts about possibly setting my references to "copy local" which might allow me to run on the 2.0 server. Thoughts?
You are right in that 3.5 runs on the 2.0 CLR, but 3.5 contains libraries and if you have used any of those, you're out of luck unless you install 3.5 on that server.
There are plenty of options for a 3.5 program to not run correctly on only 2.0, so I'd consider downgrading the program, or upgrading the server.
Note regarding copy local. Even if you copy all the 3.5 libraries that your app uses, there is no guarantee it'll work and most likely it won't. Even so, distributing the libraries with your app is expressively prohibited by the .NET license.
Since you have stated you use LINQ, the only legal way to get your app running is to install the 3.5 license.
Or, you can rewrite your app using only 2.0.
I'm pretty sure that LINQ is one of the things that makes 3.5 a requirement. A lot of the other things, like lambda expressions etc. are just compiler trickery.
Because System.Linq is a 3.5 feature, the framework is required to be that version.
A good way to determine would be to change the target framework to 2.0 and see if it builds.
Code compiled against 3.0 or 3.5 may run on the 2.0 framework, but only if you do not use any libraries that are specific to the 3.0+ framework. One good way to find what's causing your code to fail is to switch your target to 2.0 and change things so that it compiles. Since one of your target installations is .NET 2.0, you are going to have to write .NET 2.0 code; this is not unique to .NET. In the past, writing an application that executed in both Win95 and WinNT involved extra work for the developer to carefully make sure the appropriate API was used.
Technically, 3.5-targetted code can run on 2.0 with no problems, but there's some gotchas you have to watch for. If anything accesses something that is unavailable in .NET 2.0, that will fail. This doesn't happen when the application starts, it happens when the application tries to make the call. I tested this by making a console application that does a little bit of output, then tries to display a WPF window. The output is made, but the application throws an exception when it tries to display the window on a machine with nothing but .NET 2.0.
Another gotcha is that VS 2008 actually comes with the .NET Framework 2.0 SP1, and there are a few types and methods in SP1 that are not in the normal 2.0 Framework. Visual Studio will not flag these methods as unsafe.
Finally, if this is a web application, the default web.config file for 3.5-targeted projects is very different than the web.config file for 2.0-targeted projects. Make sure you're distributing a compatible web.config. This is likely the problem you are encountering. A cheap workaround might be to change your target to .NET 2.0, copy that web.config, and use it in this case. Keep in mind that if you are using any 3.0+-specific language features or types your code will still fail, but this should get you past the web.config.
You're not going to be able to run code targetted to 3.5 on the server unless you get 3.5 installed on it.
The problem isn't your code, rather that the required libraries will be missing.
This is not possible. Although the CLR has not changed (like it did between v1.1 and v2.0) The libraries have. You cannot run a 3.5 app that doesn't have the 3.5 fraework installed. All of the Linq features are made possible by the 3.5 framework.
One error is in Web.Config. The published Web.Config is setup to allow compilation from .NET 3.5, which is the reason it includes build provider information.
Beyond that, your code won't run. By using LINQ, you're referencing assemblies that don't exist in .NET 2.0.
I was just going to leave a comment by my rep is not quite there. I agree with the crowd so far and believe that lassevk's answer is the best so please give him the rep for that. One this I wanted you to know about though is that once you install 3.5 on your IIS server (6 or better). When you go to the IIS Manager and right click on your website to access the ASP.Net tab. You will see AFTER the install of the 3.5 Framework that there is no 3.5 option available. It will still show it as 2.0.50727. Don't worry about that, it will still work just fine. Because of this inconsistence (thanks Microsoft) some confusion has been caused. Actually I think this is why you may have thought that 2.0 would run your 3.5 code just fine. Hope this helps and anyone please edit this so it makes more sense.
You can may use of some C# 3 features whilst targeting .NET 2.0. Its the language features which by the time its compilied to IL will run on the 2.0 CLR regardless of whether that CLR is part of a 2.0 or higher framework install.
Hence you can use anonymous types, extension methods and Lambda expressions but as soon as you do things like LINQ you then need external libraries that are part of 3.5
If you are only doing LINQ to Object you could add the LINQBridge to your distribution.
Another problem you can run into is if you are shipping a web application that includes the source code, such as code behind files, in line code and .cs in the App_Code folder.
You can end up shipping C# source code which compiles on the developement machine with C# 3 compilier present but fails to compile on a server only equiped with C# 2. In this case you can't use any new language features either.
What's worse is that specifing the .NET 2.0 framework as the target in the Visual Studio doesn't stop you using C# 3 language features. You get no warnings that such syntax will not compile on a 2.0 machine.
Hence if you are shipping such a web app, you'll need to compile pretty much everything first.
You can just copy over the 3.5 dlls onto the server. You can absolutely run 3.5 code on a 2.0 server.