|
Again, and for the last time, it has NOTHING to do with the processor.
Since you installed Visual Studio on the bad machine, you installed a bunch of components on that machine as well. Obviously, your application reuiqres one of those components that you did not install on the target machine.
You cannot just copy your bin folder to the target machine and expect it to work. It will for simpler apps, but yours is requiring a components that has to be installed and you are not shipping with your .EXE.
How do I know this? Because the error popped up in your InitializeComponent call. You're more than likely using a control that doesn't exist on the target Vista machine.
|
|
|
|
|
my problem is solved.
i always checked my project using proper setup.
problem occured due to System.Core.dll not
found on system.........
|
|
|
|
|
That would mean that either the correct .NET Framework wasn't installed or the installation was screwed up, which is a very rare occurrence.
|
|
|
|
|
I saw some nasty code recently. A function took a parameter of a type that was something like Func<int, int,="" string,="" mytype="">. You get no clues about the parameters.
When (if ever) should we use Lambdas? They seem like a shortcut which will save some time during the initial development, but lose more time later. I think the old fashioned way will almost always be more readable.
One place where lambdas tend to be useful is when using LINQ (to SQL or Entity Framework). Is it really that good though? SQL is designed for the job, and performs MUCH better, so why use LINQ to SQL? If we have automated tests then we can fully test that the code is correctly wired up to the SQL.
|
|
|
|
|
They're useful shortcuts. Func is just a shortcut for when you don't want to define a delegate yourself. These are all pretty much equivalent:
Func<string, bool>
Predicate<string>
delegate bool MyStringTest(string s)
Lambda expressions themselves, I find extremely useful... I love being able to type:
People.Where(a=>a.FirstName.StartsWith("B"));
This use of lambdas has nothing to do with SQL, aside from a syntax resemblance between the long-form LINQ queries and SQL queries (I prefer the shorthand notation).
Remember that LINQ extensions aren't only made for database access... They're great for working with collections.
|
|
|
|
|
Exactly, it was made for querying an array of objects. If you are working with db connection you would more use T-SQL. With using lamdba's, yeah, they are handy but if the code is long, or if the method is virtual/abstract I would prefer not to and more than not, I mainly only use them in the LINQ querying on array types unless it is complex where I would return Predicate/Func/Action from a methods also where I could add some more parameters to help my need in filtering.
|
|
|
|
|
A lambda expression makes a good short-cut for many well known items, every wanted a one off-anon event, lambda, want to sort a list and not implement IComparable, lambda. However, I often refactor many of my lambda expressions into real code.
|
|
|
|
|
Ennis Ray Lynch, Jr. wrote: I often refactor many of my lambda expressions into real code
True. Same with the Nullable<T> and Tuple<x,y,z> .
Greetings - Jacek
|
|
|
|
|
Member 4487083 wrote: the old fashioned way will almost always be more readable
I'm with you, mainly because I'm old-school .
But I suppose it's similar to using a Regular Expression rather than writing a custom parser. Or even like including SQL in your code rather than calling an API of some sort.
|
|
|
|
|
PIEBALDconsult wrote: B<layer>ut I suppose it's similar to using a Regular Expression rather than writing a custom parser. Or even like including SQL in your code rather than calling an API of some sort.
Pretty good analogy actually.
Mainly because people misuse those all the time too.
And as for "custom parser" there are probably quite a few cases where people attempt to use a regex when they problem can be solved with nothing more than a simple index or split.
|
|
|
|
|
Member 4487083 wrote: When (if ever) should we use Lambdas?
Almost never.
Member 4487083 wrote: and performs MUCH better, so why use LINQ to SQL?
Perhaps to demonstrate that one doesn't in fact know exactly what you said?
|
|
|
|
|
Func is a generic type, you'd usually have information about the parameters.
Lambdas are really nice for simple functions (in the mathematical or FP sense), where the boilerplate text for defining a method would be a significant portion of the code, and where the calculation type is simple enough that everything can be inferred (by the reader; the computer has no problem anyway!). I've also seen them used for event handlers, where the parameter types are well known.
LINQ to SQL, if used correctly, creates queries very similar to what you'd make yourself, and manages the result in a much more friendly fashion. It doesn't have that much to do with lambdas though apart from the query related functions that take a lambda parameter.
|
|
|
|
|
Im trying to figure out how to create an array in my class. What I have now is:
namespace Computer_Specs
{
class Computer
{
private string _Brand;
private int _RAM;
private string _cpuBrand;
private float _cpuSpeed;
private string _operatingSystem;
private string[] _clArray = new string[5];
public string brand
{
get { return this._Brand; }
set { this._Brand = value; }
}
public int ram
{
get { return this._RAM; }
set { this._RAM = value; }
}
public string cpuBrand
{
get { return this._cpuBrand; }
set { this._cpuBrand = value; }
}
public float cpuSpeed
{
get { return this._cpuSpeed; }
set { this._cpuSpeed = value; }
}
public string os
{
get { return this._operatingSystem; }
set { this._operatingSystem = value; }
}
public string[] cla
{
get { return this._clArray; }
set { this._clArray = value; }
}
}
}
private string[] _clArray = new string[5];
public string[] cla
{
get { return this._clArray; }
set { this._clArray = value; }
}
But within my main form I don't know how to actually use the object to fill the array.
using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Linq;
using System.Text;
using System.Windows.Forms;
namespace Computer_Specs
{
public partial class Form1 : Form
{
public Form1()
{
InitializeComponent();
}
private void button1_Click(object sender, EventArgs e)
{
string nl = Environment.NewLine;
Computer specs = new Computer();
tbLog.Text = specs.brand = tbBrand.Text + nl;
tbLog.Text = tbLog.Text + (specs.ram = int.Parse(tbRAM.Text)) + nl;
tbLog.Text = tbLog.Text + (specs.cpuBrand = tbcpuBrand.Text) + nl;
tbLog.Text = tbLog.Text + (specs.cpuSpeed = float.Parse(tbCPUSpeed.Text)) + nl;
tbLog.Text = tbLog.Text + (specs.os = tbOS.Text) + nl;
}
}
}
|
|
|
|
|
List<string> claData = new List<string>();
claData.Add("Test1");
claData.Add("Test2");
claData.Add("etc.");
specs.cla = claData.ToArray();
I've just realised that you've initialised your arrays to 5 elements. This probably isn't a good idea. Whatever is using the array probably won't know it has five elements. Were you expecting something to do
specs.clas[0] = "some text" ? In this case, you can access all elements of the array (and change them) from outside the class.
|
|
|
|
|
I tested it and it worked!
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
namespace Computer_Specs
{
class Computer
{
private string _Brand;
private int _RAM;
private string _cpuBrand;
private float _cpuSpeed;
private string _operatingSystem;
private string[] _clArray;
public string brand
{
get { return this._Brand; }
set { this._Brand = value; }
}
public int ram
{
get { return this._RAM; }
set { this._RAM = value; }
}
public string cpuBrand
{
get { return this._cpuBrand; }
set { this._cpuBrand = value; }
}
public float cpuSpeed
{
get { return this._cpuSpeed; }
set { this._cpuSpeed = value; }
}
public string os
{
get { return this._operatingSystem; }
set { this._operatingSystem = value; }
}
public string[] cla
{
get { return this._clArray; }
set { this._clArray = value; }
}
}
}
using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Linq;
using System.Text;
using System.Windows.Forms;
namespace Computer_Specs
{
public partial class Form1 : Form
{
public Form1()
{
InitializeComponent();
}
private void button1_Click(object sender, EventArgs e)
{
string nl = Environment.NewLine;
Computer specs = new Computer();
tbLog.Text = specs.brand = tbBrand.Text + nl;
tbLog.Text = tbLog.Text + (specs.ram = int.Parse(tbRAM.Text)) + nl;
tbLog.Text = tbLog.Text + (specs.cpuBrand = tbcpuBrand.Text) + nl;
tbLog.Text = tbLog.Text + (specs.cpuSpeed = float.Parse(tbCPUSpeed.Text)) + nl;
tbLog.Text = tbLog.Text + (specs.os = tbOS.Text) + nl + nl;
List<string> claData = new List<string>();
int loopY = 0;
while (loopY < 5)
{
claData.Add(loopY.ToString());
loopY++;
} specs.cla = claData.ToArray();
int loopX = 0;
while (loopX < 5)
{
tbLog.Text = tbLog.Text + specs.cla[loopX] + nl;
loopX++;
}
}
}
}
My output meaning it was successful.
Dell
2
AMD
2.61
Windows XP
0
1
2
3
4
Where can I start or what would be the next thing I can move onto with classes to help broaden what I have accomplished?
modified on Friday, July 29, 2011 4:48 PM
|
|
|
|
|
Your class looks pretty good, here are some suggestions to tighten it up:
string[] _clArray;
Don't have members with typenames, this should be _cl (or _cla if the a means something other than array). For one thing it is redundant, secondly it is against naming conventions, thirdly names should be meaningful (using array might make sense in an type classing a solar panel array for example). The Microsoft guidance is not to prefix fields (with "_" for example), but I (and most of the people I know do this, as it is internal other devs won't see it (unless reading your code directly).
You should consider:
public string[] Cla
{
get { return this._clArray; }
private set { this._clArray = value; }
}
private prevents the array instance being changed from outide the class. It does lead to problems filling the array, you can do this with the class's constructor or with a specific array-setting method. Personally I'd go for the generic List<string> mentioned earlier by membernnnnnnn. With this you just create the instance inside the object and then can call the it's add method from the get accesssor. Under various circumstances you might want to make the list totally immutable from outside the class, to do this you should get rid of the public accessor you have and look at collection as readonly[^], you can then add Add and Remove methods etc that perform some validation for example.
Note also Cla your class breaks the normal .net naming conventions, you should try to keep to these: the Microsoft classes are written this way and you will confuse other devs using your code by not doing this.
|
|
|
|
|
"It does lead to problems filling the array"
No it doesn't, arr[i] only uses the get indexer. As you point out later, this is sometimes not what you want and you have to provide a wrapper.
Generally an excellent post though.
|
|
|
|
|
You are quite right, I wasn't at all clear. It would have been better put "You then have the problem of instantiating the array to the correct size for the items you are going to fill it with" which means you need to know how many items you are going to have at the ctor call, or provide a method to instantiate an array of the correct size when you do know.
|
|
|
|
|
Hi experts,
there is an application that can save some data on user request. In the application, data is held in objects that composit larger objects. Their corresponding classes inherit from one another and from abstract base classes. In order to save this all to disk it is thrown at a SoapFormatter.
SoapFormatter can again read the saved file and create the objects as they were before.
In the future, requests will change. So the classes will have to change.
Should there be any new properties to a class, I know I can add it using OptionalFieldAttribute to load. Should properties become obsolete, I can just leave them where they are, don't use them, let the storage get a little bigger than needed and have no problem with it.
How can I handle larger changes?
Is there a way to load the "old" assembly into memory, let it load the old storage file and retrieve the object structure from it programatically?
This way, "new" classes could be able to construct from "old" ones.
Ciao,
luker
|
|
|
|
|
lukeer wrote: Is there a way to load the "old" assembly into memory
Yes. Use an app domain.
But what happens in 2 years when you now have 5 versions?
If you must serialize then it is better to have a migration tool that runs independently from the app. Run it when you install the new version.
You probably better have a way to determine what version the data is in as well.
|
|
|
|
|
jschell wrote: Yes. Use an app domain.
Thanks, I'm going to research this.
jschell wrote: But what happens in 2 years when you now have 5 versions?
Well, I thought if loading the file version-5-style fails, I would have the software use the version 4 assembly, which in turn could revert to yet another earlier version.
jschell wrote: have a migration tool that runs independently
Wouldn't a separate migration tool internally use a similar approach?
jschell wrote: determine what version the data is
I already have every class serialize a version number with it.
The problem here is that if Formatter.Deserialize() fails, the serialized version number is as inaccessible as all the other saved data.
Ciao,
luker
|
|
|
|
|
lukeer wrote: The problem here is that if Formatter.Deserialize() fails, the
serialized version number is as inaccessible as all the other saved data.
Thus you need a different method.
Like a class that has nothing but a version number in it.
|
|
|
|
|
I've got a long running application what reads some data and store it in Dictioinary field.
I persist that class containing dictionary using serialization.
During the application run there is small memory consumtion going on about 1 Mb a minute.
However serialized object grows about 100 bytes a minute or less.
What is the best and fastest way to discover the reason of the leak?
Is it possible to determine exact size of that class with Dictionary collection in memory during the program run?
Чесноков
|
|
|
|
|
You'd use a .NET memory profiler like these[^].
If you're looking in TaskManager to tell you what you're app is using, don't. TM is telling you how much memory is RESERVED by the .NET CLR instance running your app, not the app itself.
|
|
|
|
|
thank you for the link... are there some tools in visual studio or windows to trace the reason of the leak?
Чесноков
|
|
|
|