|
Thanks for all the help
But i cant find any config file at all in our project
When we moved the project from diffrent computers and catalogs we notice that there become som errors in dll files, it was seartching dll files on old places and so on, and there by used older versions of dll files. We coulden find a way to solve this so we desided to pu the project catalog in C:\ and if we moved it to another computer is hade to be in the sam directory there, and this have workt well.
When we ar updating a dll file(User control(own made control)) then we only have to copy the new dll file over the new one.
But the problem with updating a serten dll file that includes in al the usercontrols simes a bit harder.
As i said, i have seartch the project catalog for a file lika *.exe.config, *.config. And i hav also lookt in the catalogs my self, but i cant find a file with that name.
//Jimmy
|
|
|
|
|
You have to create the .config file. How can you have worked with .NET for as long as I know you have (and probably longer) without ever knowing what a .config file is? You can also add a new XML file called App.config to your project and it gets renamed and moved to the target directory when you compile.
When you deploy your application, you make sure the .config file is named the same as your application and in the same directory. For ASP.NET applications, it should be called Web.config. There is plenty of documentation about .config files in the .NET Framework SDK, including the parent section of the link I sent you before.
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|
Hehe
yes i wounder the same thing, we have never been tought this thing in school.
and yes you could have learn it my self, and i have tryed, but never manage to understand it. But you have helpt me a great deal, i will try this thing out and see how it goes.
Alot of thanks
//Jimmy
|
|
|
|
|
I never learned any of this (or much of anything I didn't know already about C/C++ and Java) in school either, but yet I know it.
The key is to read. Read that link I sent you in the first reply. It shows you want to put in your .config file as I did. Understanding .config files is also very important. It allows you to custom your application without having to recompile (like storing database connection strings in the appSettings section or something). It also allows you to redirect your assembly binding as we've been talking about.
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|
No, but beleve me, i work with Programin in C# all the time, and i allways goes out side the lessons bounderys, so i think its wary strange i havent bumped in to this earlier.
And yes i read, but its hard to understand, maby i have to bad ground knowlege.
Anyway
I have made a XML file cald App.config in the project, and i saw that it created a config file named GameClient.exe(not GameClient.exe.config) but it stated that it is a config file.
I have copy the new version of Transfer in to my project, and then open the project, but some of the controls dispare from the form and in the task list it stated ex
Warning: The dependency 'Transfer, Version=1.0.1596.41878, Culture=neutral' in project 'GameClient' cannot be copied to the run directory because it would overwrite the reference 'Transfer, Version=1.0.1602.28586, Culture=neutral'.
The own made control is compiled with the version 1.0.1596.41878 and the config file simes not to work, is there any debug funktion on a XML file? so i know what i have done wrong?
//Jimmy
|
|
|
|
|
Snowjim wrote:
I have made a XML file cald App.config in the project, and i saw that it created a config file named GameClient.exe(not GameClient.exe.config) but it stated that it is a config file
Because you aren't showing all file extensions like a development machine should have. Any registered extensions are hidden. Change this in your folder options for Windows Explorer.
When you work with a multi-project solution, you should set up Project references, not assembly references. This makes sure that the assemblies are in sync: that the right versions are used to compile against and that the right buileds (i.e., Debug, Release, or custom builds) are used.
Again, don't use automatic versioning. In multi-project solutions you'll loose control quickly and it becomes a nightmare to maintain the assembly redirections. You only need to change and redeploy the changed assemblies and the .config file (or have the installer update the existing .config file) but if you use assembly redirection even while testing new versions of your assembly, you have to update the .config file each time. If you redirect to the wrong version you will get exceptions as if the right assembly version wasn't found when JIT'ing your IL.
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|
Thanks for all help!
Im not realy understand how it works, but i will have to look it up.
Anyway, we will try to set Transfer.dll to version 1.0.0.0 and then recompile the controls once and for all. After this we hope that if we make a change in the Transfer.dll we will not have to update al the controls. Yes we will not see what version is the newest, but we can always se on the date when the file is created.
//Jimmy
|
|
|
|
|
What's not to understand? Besides being documented in practically every way you can think of in the .NET Framework SDK, the concept is simple: you have an application and an application configuration file (App.exe and App.exe.config). They go into the same directory. Some settings you can use your application such as the appSettings section via ConfigurationSettings.AppSettings. Some the CLR uses when loading your application, such as assembly binding. Put the XML like I showed you before in that .config file and when the CLR tries to load an older assembly that another assembly references, your .config redirects it to a newer version. So long as the assemblies are compatible, there would be no problems. This is all outlined rather clearly in the SDK. If you don't get it after reading that and my numerous attempts to explain it, then I'll guess you'll have to recompile your client and server applications every time and deploy them in their entirety.
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|
I have understod that.
But this simes only applying to a compiled program(exe file)
I need it to applay even when i start upp the project in Visual Studio.net. I have created a file as you explaned(app.exe.config) and it have got the right name at compilation. But if i close the Project, and copy a new dll file over the old(and ofcours change the version nr in app.exe.config) and then open the project, some controls will be lost due to version errors. I guess that this config file onlye applayes to the compiled file?
And this i dont find any information about, but in general i have problem to understand some of the msdn articles so maby its not that strange.
Anyway, i understand your frustations.
//Jimmy
|
|
|
|
|
No, I said create a file in VS.NET called app.config. VS.NET will automatically rename and copy this file to the target directory with the proper name.
You don't need to do this in VS.NET, though. It's a simple text file - an XML file to be exact - with a .config extension, just like the Web.config file. VS.NET will not benefit from this .config file (at least not until VS.NET 2005) nor will it help you construct it. You need to understand the simple concepts provided in the links I gave you originally. All you're doing is telling the Common Language Runtime (CLR) to bind to a different version of an assembly when a particular version (or version range, which can be used in the oldVersion attribute) is required.
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|
Yes.. i have understand so far, its a regular file with exe.config on the end, and that i can add it by my self or by using Visual Studio. But i diddent know that is only applays to the exe file.
I dont see the point on just adding the new dll file to the exe file, not in our case. there will not be any code in our client that can handle the new funktions in the dll file.
I dont know if we understand eachother.
If i take it again.
We got a client and a server. The Client contains alot of "WindowsControlLibrarys"(own made controls) and this controls includes this Transfer.dll(Collections of classes) that countains all the Classes that we sends between the client and server.
The Transfer.dll file is located in C:\Project\Client\bin\Debug and all the "WindowsControlLibrarys"(own made controls) is including this file at this location(C:\Project\Client\bin\Debug), even the client is using this file itself.
So we hoped that if we compile the "WindowsControlLibrarys" that points at the same Transfer.dll loacated in C:\Project\Client\bin\Debug and includes it to the client, then if we need to update the Transfer.dll we only Close the project, copy the new one over the old one in C:\Project\Client\bin\Debug and then starts up the project again, and by that we dont need to recompile the "WindowsControlLibrarys", but this dident work becourse the "WindowsControlLibrarys" states what version that is included, and tryes to copy this to the C:\Project\Client\bin\Debug directory, witch it cant do becourse there already is a new version.
Then i think of : The "WindowsControlLibrarys" dont need to know of the update in the Transfer.dll, only the client need to know, so if we change the version on the transfer to 1.0.0.0 and recompiles the "WindowsControlLibrarys" with this Transfer.dll then in next update of the Transfer.dll it will not complain becource the new version have the same version(nr 1.0.0.0), and the client will be abled to use the funktions, and maby the own made controls will not aomplain about versions.
This is not a good way to solve this on, becource we will not know what version we are using, insted we will have to look at the date of the file creation.
Proberly this is totaly wrong way to do things, but maby it could work.
I have ready the links, but i cant get it to work in the project, and it simes like it is not supose to do that eather?
//Jimmy
|
|
|
|
|
Thank You.
Sorry For Bad English.
|
|
|
|
|
Not knowing English very well is no excuse for a such a long subject. Next time, please use a brief subject and explain your subject in your post's body.
There are many installers available. The setup and deployment projects in VS.NET are a joke, so forget using them. You might instead take a look at Wise Solutions[^] or InstallShield[^].
Being also an installer author (using the Windows Installer technology), let me tell you that having 59 objects from which the user is to select is not a good idea. Would you like to go through 59 options and decide which to install? I seriously doubt it. I know that I and many others would not.
It's your product: make it easy for the user to install. Combine those 59 options into fewer options with a larger scope or break them down into a tree structure (like Windows Installer features can do).
Think about Microsoft Office. There's probably about that many features in an Professional installation, but they combine them under Word, Excel, Outlook, etc. If users want to be more specific about which options to install under those, they can drill down and select more specific features.
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|
Dear, Sir
Thank You very much for your reply.
My goal is I want to create installer that have tree structure like Microsoft Office Installer.
Is setup and deployment projects in VS.NET can create an installer like Microsoft Office installer?
If it can, how to?
Thank Again.
|
|
|
|
|
No, because the VS.NET installer project does not allow you to specify features or even have a feature dialog. Instead, use Wise for Windows Installer[^] or InstallShield for Windows Installer[^]. I recommend Wise. I've worked with both since Windows Installer 1.0 and each's 1.0 versions and Wise has always been completely extensible (giving you access to all the advanced features of MSI through a table UI) and not nearly as bloated or expensive as InstallShield.
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|
How can I create a listbox with each item presented by a combobox?
Thanks in advance.
|
|
|
|
|
One idea would be to use owner drawing and in your handler for the DrawItem event (or, if you extend ListBox - which is a better idea for enscapsulation - override OnDrawItem) and use the DrawItemEventArgs.Bounds to position an instance of a ComboBox tied to each item. The trick is to make sure that the ComboBox instances are created and disposed when an object is added or removed from the ListBox. The best way is to extend ListBox.ObjectCollection with your own collection class and override ListBox.CreateItemCollection so that you return an instance of your derivative class.
To make sure that Windows messages are properly dispatched, you may need to add each instance of the ComboBox to the ListBox.Controls collection property. Never tried this, so I'm really not sure. All the owner-drawn ListBoxes I've written and have seen simply draw the items.
See the documentation for the ListBox.DrawMode property in the .NET Framework SDK for more information on owner drawing with a ListBox.
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|
|
I am attempting to produce some code that performs fairly simple LDAP queries, unfortunately I can't seem to get this running. The code I currently have is :
private void GetProps()
{
int LDAP_PORT = 636;
string LDAP_IP = "111.222.333.444";
string ID_CODE = "X246555";
string ldapPath = string.Format("LDAP://{0}:{1}/o=testo/ou=Services", LDAP_IP, LDAP_PORT);
string filter = string.Format("(&(IdCode={0})(sname=urn:this:that:something:or:other))", ID_CODE);
DirectoryEntry de = new DirectoryEntry(ldapPath);
using (DirectorySearcher searcher = new DirectorySearcher())
{
searcher.SearchRoot = de;
searcher.Filter = filter;
searcher.SearchScope = SearchScope.Subtree;
searcher.PropertiesToLoad.Add("prop1");
searcher.PropertiesToLoad.Add("prop2");
searcher.Sort = new SortOption("prop1", SortDirection.Ascending);
SearchResultCollection results = searcher.FindAll();
foreach (SearchResult result in results)
{
Console.WriteLine(result.Properties["prop1"]);
Console.WriteLine(result.Properties["prop2"]);
}
}
}
This code is born of various docs found on the net and also within MSDN, when run it fails with this error :
Unhandled Exception: System.Runtime.InteropServices.COMException (0x8007203A): The server is not operational
The thing is I know that the server is running and configured correctly as I can perform the same query from the same machine via OpenLDAP and this returns exactly as expected.
If anybody could help me out here I would truely appreciate it.
post.mode = postmodes.signature;
SELECT everything FROM everywhere WHERE something = something_else;
> 1 Row Returned
> 42
|
|
|
|
|
On what exactly is the exception thrown? I'm guessing searcher.FindAll().
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|
You guessed correctly
post.mode = postmodes.signature;
SELECT everything FROM everywhere WHERE something = something_else;
> 1 Row Returned
> 42
|
|
|
|
|
Specify at least AuthenticationTypes.ServerBind for DirectoryEntry.AuthenticationType. According to the docs:If your ADsPath includes a server name, specify this flag when using the LDAP provider. Do not use this flag for paths that include a domain name or for serverless paths. Specifying a server name without also specifying this flag results in unnecessary network traffic. Your ADsPath includes the server name, so you must bind to the server. If you don't require write access, you might also specify AuthenticationTypes.ReadonlyServer (the AuthenticationTypes enumeration is attribute with the FlagsAttribute so you can OR themn together using |).
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|
Thanks alot for the suggestions, unfortunately I had already tried the various flags with no result.
Now the rest of this post is in "thinking out loud" mode, but if anybody has a clue feel free to join in 
The LDAP server I was attempting to connect to is beyond my control, so while playing around I have setup my own ldap server (OpenLdap)
Now if I run the server using the default LDAP port I can connect and retrieve data using the following paths :
string ldapPath = "LDAP://10.139.42.89:389/dc=domain,dc=com";
string ldapPath = "LDAP://10.139.42.89/dc=domain,dc=com";
I can also use the openLdap LdapSearch tool to retrieve data aswell 
If I start the server using any other port, say 9898, when I attempt to retrieve data using the following path it fails :
string ldapPath = "LDAP://10.139.42.89:9898/dc=domain,dc=com";
This fails on FindAll() with "The Server is not operational"
But I can still perform searches to that port using the openLdap ldapSearch tool 
So I thought that maybe the .NET framework was ignoring the port and always going to the default (389) but if I run the server on the default port and use the following connection string :
string ldapPath = "LDAP://10.139.42.89:9898/dc=domain,dc=com";
It still fails 
Every single document I look at advises that ldap connection paths should be formatted in the way the ones above are, which I assume is correct as I can make connections to the default port either by specifying or not - but it doesnt explain why I cannot connect to non default ports.
post.mode = postmodes.signature;
SELECT everything FROM everywhere WHERE something = something_else;
> 1 Row Returned
> 42
|
|
|
|
|
Of course the last example is going to fail; the LDAP server isn't running on port 9898.
The questions you have to start asking yourself are about authentication more than likely. For example, when you use the OpenLDAP tools to search the directory, are you specifying any credentials or other options besides the server to bind to and the query?
Also, regardless of whether or not you're having problems, you'll still need those flags I mentioned before to bind to the server if it's in your ADsPath.
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|
Although the authentication flags are important, I am fairly certain they are not the cause of this problem (I am currently using AuthenticationTypes.ServerBind | AuthenticationTypes.ReadonlyServer)
While testing the connection strings detail above the only changes that are made are :
- changing the port in the declaration of "ldapPath".
- changing the port that the LDAP server is listening on.
Whilst on the default port (389) everything works as it should, connections can be made and I can perform queries which return exactly what I would expect them to.
According to ldap docs changing the listen port is just that, nothing else changes so the way the C# client authenticates shouldnt need to change either.
I have also downloaded a few different ldap browsers, all of these work regardless of the port the server is listening on, and I am 101% certain I am using the correct connection details (if I wasnt I wouldnt be able to connect on the default port). There is something odd afoot here, and I will be damned if its going to beat me.
post.mode = postmodes.signature;
SELECT everything FROM everywhere WHERE something = something_else;
> 1 Row Returned
> 42
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
