I recently wrote a c# program on framework 4, before realising the entire company runs 3.5.
This is a problem mainly because of the charting support.
My question is: is it possible to just embed the dlls that would be missing in the application? So .net is on the machine, just missing some parts that are packaged with the app.
Thanks for any feedback!
You will have trouble doing this because .NET 4 runs on a new version of the runtime, CLR.
I think your best and safest bet would be to try and compile the project for Framework 3.5. Of course it depends on the size and which features you have used, but I don't think you should have much trouble converting. Of course, if you rely heavily on new features, such as dynamic, it might not be so easy.
Yes you can. Just consider the new features of .net framework 4 as a third-party charting library. But make sure that (1)you've involved all necessary dlls. (2) you didn't use other new features of .net 4 besides charting.
Are you using any .NET specific code? If not you can just rebuild the application and target .NET 3.5, its a simple setting change in project properties take a look here:
http://msdn.microsoft.com/en-us/library/bb398202.aspx
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 have an application called NinjaTrader that uses .Net 3.5. I have a Strategy that will send order information to a .dll written in .Net 3.5. I need to send this order information to a platform called T4 that currently uses .Net 4.0. I thought about using C++ as my .dll however everything still seems to target "some" .Net assembly. I am currently using a asynchronous client server connection that does a decent job. I just think it would be better to just run it through a .dll or something. Does anybody have any ideas of the most stable solution?
If you're planning on using .NET from C++ you would need to use C++/CLI.
Also, in order to use CLR v4 you would need your project to run in .NET 4.
See this question.
The best solution IMO would be to just recompile your project to target .NET 4. There shouldn't be many changes to make in your project assuming it's not a huge project. Have you tried recompiling for .NET 4?
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.
Ive recently been asked to recommend a .NET framework version to use in a (GUI based) project for an XP machine.
Can anyone explain the differences between all the .NET versions?
OR,
Does anyone have a good reference to a site that details (briefly) the differences?
Jon Skeet's book C# In Depth has one section describing versions of .NET in details.
The only reason to not go for the latest version is that it can complicate deployment.
.NET 2.0 is installed automatically via Windows Update, so you can expect it to be on the target computer when your deploy your application. .NET 3.5 is not being pushed automatically yet, so you need to distribute the framework with your application. This will probably change in the near future.
If you are not concerned about deployment, then go for the latest version. The fact that you target the .NET 3.5 framework, does not mean that you have to use all the new technology. For instance you can still use Windows Forms instead of WPF, but that is another question.
The short answer is that it depends.
.NET 2.0 is the oldest version you should be considering.
.NET 3.0 is an easy upgrade path from 2.0, not the same amount of breaking changes as from 1.1 to 2.0. However it is more of an extension, horizontally of functionality, and you would not see a huge shift in graphical options.
.NET 3.5 should be looked at if you are interested in much more sophisticated gui such as sliverlight. It has a lot more new technologies and options to offer including WPF, a new IDE in Expression and much more. http://www.asp.net would not be a bad start.
This page is good for a list of changes:
http://en.wikipedia.org/wiki/Microsoft_.NET
As someone has already mentioned, .NET 2.0 is the minimum version you need to look at. Things like Generics make it a must have.
.NET 3.5 is the other version you should consider. It depends on how you want to design your projects, .NET 2.0 is very developer central, whereas .net 3.5 has a good split between designer and developer.
It doesn't really matter much. .NET 2.0, 3.0 and 3.5 all use the exact same CLR and base classes. Each version just adds a set of new assemblies. For GUI development, you're fine with 2.0 if you use Windows Forms, you'll need 3.0 for WPF. Since they are otherwise essentially identical, there is no good reason to not just install 3.5 SP1.
Our clients use a vb6 version of our software.
We are upgrading them to a .NET application written in C#...
Is there less bulk using .net 2.0 than .net 3.5?
My definition of less bulk would be: Smaller size, smaller installation time, etc.
Most of them probably already have 2.0 anyway.
I only ask because I would like to take advantage of LINQ in 3.5.
For taking advantage of LINQ, you need 3.5 (unless you want to use LINQBridge with 2.0).
For a smaller installer, .Net 3.5 Sp1 has a new feature called "Client Profile".
The .NET Framework Client Profile setup contains just those assemblies and files in the .NET Framework that are typically used for client application scenarios. For example: it includes Windows Forms, WPF, and WCF. It does not include ASP.NET and those libraries and components used primarily for server scenarios. We expect this setup package to be about 26MB in size, and it can be downloaded and installed much quicker than the full .NET Framework setup package.
Is not installing .NET 3.5 just to save a few Mb really that much more important that gaining a huge increase in productivity with LINQ and other .NET 3.5 features?
Why start off behind in technology?
The .Net 3.5 runtime is ~50Mb. The 2.0 runtime is ~23Mb.
But if you control the deployment or installation, that really shouldn't be an issue. This is especially true for 'clients' vs 'customers', and the word client involves and on-going, personal relationship. If it comes to it, send them a CD. Then anything under 700Mb is all the same.
Check out LINQBridge:
http://www.albahari.com/nutshell/linqbridge.aspx
Adding LINQ support to .net 2 (.net 3.5 still uses CLR 2.0).
.NET 3.5 is .NET 2.0 + more libraries and extensions, so yes, the install is bigger. In my opinion however, it is very much worth the extra bulk because of the extra stuff it gives you.
If it's a VB6 app, you should check which Windows versions the app is currently used on, and select the .Net version accordingly. AFAIK 3.5 does not run on W2K.
If you would like to take advantage of LINQ, then go for 3.5! I find there's not more 'bulk' when using it myself, but unless you want to use LINQ, then either is fine.
Keep in mind that certain OSes (Windows 2000 Server) won't let you install .NET 3.0 or 3.5, so you may have to stick with 2.0 for that reason.
I would suggest that you go straight with visual studio 2008 and .net 3.5 sp1,
2.0 is the basis of 3.5 and you can easily start using 2.0 and then start to use 3.5 functionalities.
Furthermore 3.5 SP1 also brings tweaks to the 2.0 framework which are nice to have.
I suggest you to go directly to 3.5 because you will be less far away (in the future ... in 3-5 years) to change to other version of framework. If in 5 year .Net is at version 5, the jump will be smaller to do. So, VB6 to 3.5 is what I suggest you.
The size of the framework is not very high, less than 60 megs... not a big deal now I think.
Also note, depending were you install the .NET framework it might be irrelevant how much extra bulk there is. The .NET Framework installs are relatively small in modern terms.
As for LINQ, it will save you a lot of time and effort, and offers a quick way to get at data. However it also depends on the clients the application will be distributed out to.
I'd say at that, go with 3.5 unless there is another major roadblock on the clients for whatever reason.
As others have pointed out, the .NET 3.5 install is longer and larger than .NET 2.0. Keep in mind that .NET 3.0 and .NET 3.5 are both extensions on top of the .NET 2.0 CLR.
I would still say upgrade from VB6 directly to .NET 3.5 (actually .NET 3.5 SP1) and VS2008, as long as your client operating systems support that version of the Framework (otherwise you will need to choose the lowest common Framework version, which very well may be .NET 2.0). You will save yourself a lot of time/effort in the long run.