|
i am not sure my giving this solution that, is it true or no ? but please try to solve your prblem.
firt, capture the value from the combo box and than check its with other columns which you want to made uneditable by apply the contion that if the particulare item is selected from the combobox than set the editable property of that columns.
|
|
|
|
|
Dear,
You can try in this way. You can use the method FindControl of the datagrid item to find the control in your datagrid
<br />
Dim x as new control<br />
for each x in datagrid.controls<br />
...<br />
next<br />
You use this code to show all the control in the datagrid, then you can try deeper into the datagrid item to find your combobox... then you can use the method findcontrol in the datagrid item to get value and set value for your control.
PS: I'm not sure if the code is correctly right or not. But that's the idea. I did well in ASP .NET
Ich liebe .NET 
|
|
|
|
|
Does Microsoft specify a way to determine whether the .net framework is installed?
I'd like to use that in a NSIS-Skript.
thomas
|
|
|
|
|
From http://blogs.msdn.com/junfeng/archive/2004/02/05/67815.aspx[^]
For v1.0:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\policy\v1.0]. If REG_SZ value 3705 exists, then .Net framework v1 is installed.
For v1.1:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\policy\v1.1] ...test the existence of REG_SZ value 4322.
Charlie
if(!curlies){ return; }
|
|
|
|
|
Also if you search the user contributed stuff on the NSIS website they HAD a function for determining if .NET was installed and would download it from the MS website and install it for you.
Steve Maier, MCSD MCAD
|
|
|
|
|
OK, i now finally have one that satisfies me. It can be found under http://nsis.sourceforge.net/archive/nsisweb.php?page=537&instances=0,110 and checks whether a minimum version of .net is installed.
the one you mentioned downloading .net is a bit too quick and dirty; it just checks
IfFileExists "$WINDIR\Microsoft.NET\Framework\v1.1.4322\installUtil.exe"
thanks
thomas
|
|
|
|
|
Hello,
I have a problem when building my project. Everything build fine, but I just have to build way too much. I'm sure that there is an 'easy' solution, but I don't know where to look.
I have a project that consist out of maybe 50 seperate dll's (probably around 40 are self developed and the others are bought from other vendors). The dll's are all strong named and offcourse there are dependencies between them.
Suppose I have following structure
Model.dll (-> classes used in every program I use (like customer, adress, ...)
Data.dll (depends on Model.dll -> classes to connect to mssql, access)
Diary.dll (depends on Model.dll and Data.dll -> program that represents a diary)
Statistics.dll (depends on Model.dll and Data.dll -> program that represents a statistical program)
Suppose that in the data.dll I have a method like the following (It's just an example)
public int GetSomeData (int _Test)
{
if (Test == 0)
return 1;
return -1;
}
Now I want to make the function like this
public int GetSomeData (int _Test)
{
if (Test == 0)
return 1;
else if (Test == 1)
return 0;
return -1;
}
I need to rebuild the data.dll offcourse. But because of the strongnaming I also have to recompile the Diary.dll and the Statistics.dll
This is somehow cumbersome and nothing changed in the code for these dll's.
My question now is: How can I rebuild the data.dll and not recompile it's depending dll's without breaking the dependency and knowing that all dll's are strong named? Or where should I be looking to solve this problem?
Thanks in advance,
Best regards,
Ike Casteleyn
icasteleyn@hotmail.com
|
|
|
|
|
Probably an easy answer to this one, but I can't see it.
I have a simple shared Assembly (Strong Named) packaged into a .msi for deployment on client machines.
I create the package using Microsofts Knowlwdgebase Q324168
"HOW TO: Deploy an Assembly to the Target Computer Global Assembly Cache"
It says
1. To the Solution that contains the project, add a new Setup Project that references to the assembly.
2. Right-click File System on Target Machine, click Add Special Folder, and then click Global Assembly Cache Folder.
3. By default, the assembly is inserted in the Application Folder (by default, it is a side-by-side installation). Drag the assembly to the Global Assembly Cache Folder.
4. Build the Setup Project.
I run the Setup on the target machine and all works fine.
The thing is I can't find the installed dll file anywhere on the client.
I have two applications sharing this dll and no clue of where it sits on the hard drive.
Does installing to the GAC cause an assembly to be treated differently?
Any ideas, would really appreciate any insight into this.
John
|
|
|
|
|
JohnARyan wrote:
Does installing to the GAC cause an assembly to be treated differently?
Yes.
The actual assemblies in the GAC are stored in %WINDOWS%\assembly, but the search feature in Windows Explorer won't be able to find them there. To view the contents, you can either use the shell extension provided (the folder will be viewed using the extension if you browse there with Windows Explorer) or the command-line tool Gacutil.exe.
gacutil.exe /l will list all the assemblies in the GAC while gacutil /l myassemblyname will give you the information for any matches it finds. (Note that you provide the assembly name, not the DLL name, so do not give the .dll extension)
I've found that an assembly won't be put into the application folder if it is placed in the GAC folder *and* it is excluded in the Detected Dependencies folder in the setup project. (Its icon will be shown in black and white and there will be a little circle with a cross through it.)
Charlie
if(!curlies){ return; }
|
|
|
|
|
Ok, time to ask the question here.. I have been battling over this one for sometime now and just have to ask it.
I have created a few classes that I use to act a security keys. These classes get serialized using a binary formatter and then symmetrically encrypted. The app will deserialize them and use the contents to judge licensing capabilities, etc…
Currently the license key and vectors are stored in the code. I don’t like the idea simply because it allows someone with a decompile to get at them. Yes, I can obfuscate the code but being paranoid like I am I have a feeling that is just not enough.
My real biggest fear besides the fact that someone can use the key to decrypt the data is that someone can also use the same key to create a program that will generate fake license keys for my app.
In another case I have to send a class across a wire on a remoting channel and the class is going to have a users name and password in it. Again, being the paranoid programmer that I am I am really afraid of someone with a sniffer out there looking at the raw bits. I would like to encrypt the password before I send the class across the wire. Again, I know that I can just hard code the keys into the app but we all know what I feel about that.
I know that I could use asymmetrical encryption and that gives me the ability to release a public key that can only be used to decrypt and that takes care of part of it but from what I have seen asymmetrical encryption is a royal pain in the butt because it only encrypts data of a maximum size so I would have to take that into account when I am serializing data and possibly split the data up into checks, each one encrypted…. Not a clean option really…
I know already, I have read tones of thing on remoting and how to build encryption sinks to be used for cases like this, but I really don't need to encrypt the entire message, just one part of it.
There HAS to be a way to reliably use symmetrical encryption without hard coding the keys into the code but also protecting them from being used by other people.
Any simple ideas to this tough question?
Paul Watson wrote:
"At the end of the day it is what you produce that counts, not how many doctorates you have on the wall."
George Carlin wrote:
"Don't sweat the petty things, and don't pet the sweaty things."
Jörgen Sigvardsson wrote:
If the physicists find a universal theory describing the laws of universe, I'm sure the a**hole constant will be an integral part of that theory.
|
|
|
|
|
Do you really think its worth the effort? As you have mentioned .Net assemblies can be easily decompiled. So even if your encryption is 100% safe a skilled programmer can still disable the whole licensing check.
|
|
|
|
|
Use hashing with salts. It basically works like this. You hash each user's password and store the hash on the server. The client also hashes the password entered and sends the hash to the server. The server verifies that the hashes match. To avoid dictionary attacks, you can use salting, where each user is assigned a random string which is appended to his password and the whole thing is hashed.
For a better technique and explanation, have a look at this link http://blogs.msdn.com/ericlippert/archive/2005/02/07/368569.aspx[^]
|
|
|
|
|
Recently, code was added to a Visual Studio .NET solution that includes .net dependencies. Previously, the solution had all MFC code. Now InstMsiW.Exe and InstMsiA.Exe don't appear in the output folder when the setup project is built. Is this something to be concerned about?
Thank you,
|
|
|
|
|
NET dependencies imply NET framework must be installed. The NET framework install automatically checks for the Windows Installer (and upgrades depending on the version found).
So the assumption is that when your project is dependent on NET you no longer need the InstMSI's, because of one of two reasons:
1) The NET framework is already installed so the Windows Installer service was installed/updated and does not need to be bootstrapped.
2) The NET framework will have to be installed, in which case the NET framework will take care of bootstrapping Windows Installer.
So including InstMSI in any setup that installs NET assemblies is pointless.
But there is a problem: Now instead of needing to bootstrap the Windows Installer (i.e. include InstMSI) you need to bootstrap the NET framework, because it might not exist on the target machine.
But unfortunately you cannot just add the NET framework install to your setup like you did with InstMSI.
See the MSDN for what is now required to deploy apps with NET dependencies:
http://support.microsoft.com/default.aspx?scid=kb;en-us;324733[^]
Robert
|
|
|
|
|
Has anyone ever tried to code a piece of software to browse his bank(hsbc for instance) accounts, buy sell stock shares thru this software. This software is not meant to be only with ASP.NET, it can also be built using MFC or any other related libraries of .NET framework or previous Microsoft related libraries. I have got a similar piece of code in Java, however I would like to study its .NET version, what would it be like and what libraries of framework would be used, what methods be called to make a connection to the bank's server, browse accounts and buy and sell stock shares. I am trying to code a non-asp version of it for http://www.hsbc.com.tr/. Does anyone have any idea. I would later automatize my buying and selling thru some technical indicators..
Thank you for any opinions..
born to ask
|
|
|
|
|
I am using .Net remoting in windows 2003.
Remoting channel i am using is "pipe".
Now the problem is i am not able to get the proxy object for the remote object.
my config files are:
for client:
------------
<configuration>
<system.runtime.remoting>
<application>
<client>
<wellknown type="CECAdapter, ArECA" url="pipe://MyPipe/ecadapter.rem">
<client>
<wellknown type="ConfigMgr, ArConfigMgr" url="pipe://MyPipe/ConfigMgr.rem">
<client>
<wellknown type="DCEventManager, ArSysEventMgmt" url="pipe://MyPipe/DCEventManager.rem">
<client>
<wellknown type="RegnServer, ArRegnServer" url="pipe://MyPipe/RegnServer.rem">
<channels>
<channel type="Remoting.Pipe.PipeChannel,Remoting.Pipe,Version=1.0.1.0, Culture=neutral,PublicKeyToken=151990e70f5d092b" pipe="Auto">
for server:
------------
<configuration>
<system.runtime.remoting>
<application>
<service>
<wellknown mode="Singleton" type="CECAdapter, ArECA" objecturi="ecadapter.rem">
<service>
<wellknown mode="Singleton" type="ConfigMgr, ArConfigMgr" objecturi="ConfigMgr.rem">
<service>
<wellknown mode="Singleton" type="DCEventManager, ArSysEventMgmt" objecturi="DCEventManager.rem">
<service>
<wellknown mode="Singleton" type="RegnServer, ArRegnServer" objecturi="RegnServer.rem">
<channels>
<channel type="Remoting.Pipe.PipeChannel,Remoting.Pipe,Version=1.0.1.0, Culture=neutral,PublicKeyToken=151990e70f5d092b" pipe="MyPipe">
Can any body help me to resolve the issue.
|
|
|
|
|
You should select "Do not treat <'s as HTML tags" or encode the brackets with & l t ; and & g t ; (no spaces)
Charlie
<font color="blue">if</font>(!curlies){ <font color="blue">return</font>; }
|
|
|
|
|
I'm having some inconsistency problems with my deployment project ("Setup") and its custom actions ("Installer"). I'm using Visual Studio .NET 2003 (.NET 1.1, no service pack) on Windows XPSP1.
My main project is a band object (Explorer Bar) in an assembly (.DLL) that needs to be registered on installation and unregisted on uninstallation. In addition, during installation, Setup creates registry subkeys, sets registry values, installs some application files, and adds a new file-type. On uninstallation, Setup is supposed to undo all of that. More specifically, I have custom actions for Setup that are run within the Installer class. The Installer class is within the main assembly, and perhaps surprisingly, that seems to work, some of the time. I have also tried putting the Installer class in its own assembly, both as a class library and as a console application, and that doesn't seem to work any better than having the Installer class in the main assembly. Sometimes the registration or unregistration of the main assembly fails. The workaround we tell our users (a small userbase so far, fortunately) is to "repair" after installation, or to uninstall completely before installing a new version. Neither are as ideal as being able to simply install over the previous version. I think there are two subproblems.
1) The Uninstall custom action in the Installer class isn't always called. This is especially inconsistent. My Installer class overrides OnBeforeUninstall() [so that the main assembly is unregistered before the files are removed] and Uninstall() [so that savedState is empty, in order for the installState to be removed]. Lacking better debugging tools for MSIs, I added code in these methods to set registry entries containing the timestamp at the beginning and end of each of these methods. I verified that usually the Uninstall custom action is (but not always) called when the user explicitly asks to remove the package (via "Add/Remove Programs"), but when the user is installing over a previous version, sometimes (but not always) the Uninstall custom action is called. As a side note, I change the installer version, PackageCode, and ProductCode whenever I build a new installer. I don't understand why these inconsistencies occur. For a while I thought VS.NET might randomly corrupt the Setup.vdproj file and that I'd have to remove and add the custom actions again, in order to be sure that the Uninstall custom action was registered, and once or twice I built the Setup.vdproj file from scratch, fearing general corruption in the file. This seemed to help (especially the latter), but not for too long, and it's not a sustainable solution, even if it's not a placebo. In addition, which may or may not be related, the Setup.MSI doesn't seem to always uninstall all registry entries, and because of that, I've had to add a few lines to my Uninstall custom action. It doesn't seem right to me that the MSI would sometimes not uninstall registry entries that it added in the first place.
2) The second subproblem is more specific to my project, and this occurs sometimes when I'm registering the main assembly. The main assembly is registered in the overridden OnCommitted() method of the Installer class, presumably after the previous version's main assembly was unregistered in the OnBeforeUninstall() method. In the case where the previous version and the new version were installed in the same "Program Files" folder, the assembly containing the Installer class will have the same exact CodeBase, but they'll of course have a different FullName because the assembly version has been automatically incremented. It seems that sometimes the Commit custom action will re-register the old assembly instead of registering the new assembly. My registration code looks like this:
RegistrationServices rs = new RegistrationServices();
rs.RegisterAssembly(MyAssembly, AssemblyRegistrationFlags.SetCodeBase); and my unregistration code looks like this:
RegistrationServices rs = new RegistrationServices();
rs.UnregisterAssembly(MyAssembly); MyAssembly is defined as a property:
Assembly MyAssembly
{
get
{
return Assembly.LoadFile(InstallDirectory + "assembly.dll");
}
}I used to use Assembly.Load(path) instead, but it seemed that Assembly.LoadFile(path) worked better. My concern is that either the Uninstall and Commit custom actions share an AppDomain, so sometimes MyAssembly might return the previous assembly during the Commit phase if the previous assembly wasn't somehow still in Commit's AppDomain after Uninstall finished. I tried creating a temporary AppDomain and then loading the assemblies within that, but it threw a deserialization exception. I suppose the overall issue of this subproblem is that I'm trying to register and unregister assemblies without knowing the FullName of either assembly, as I'm trying to semi-automate the build process and stay within VS.NET as much as possible (for now).
I know these are complex and possibly peculiar problems! While I'd love for someone to post a solution for either (or both!) subproblems, at the very least, I'd appreciate hearing tips regarding debugging deployment projects and custom installation classes, similar stories of installer woes and solutions, and recommendations for possibly better installation/deployment tools than VS.NET's deployment projects. Something like InstallShield seems like overkill, but maybe it's what I need to have dependable installations.
Thanks for reading this far!
Arun
|
|
|
|
|
This is not much help. I've had problems with running custom actions on uninstall as well and I have not yet resolved them.
One thing you can do to at least try to get some more information is to create a full log file of the installer actions.
Run your msi package from the command line using the following verbose logging command line options and it will generate a complete log. Unfortunately, interpreting the log is another matter, and acting upon that interpretation still another ... 
But it is a starting point at least.
Typical command line is:
msiexec.exe /L*v "C:\MySetup.log" /I "C:\MySetup.msi"
i.e.
msiexec.exe /L*v <fully qualified path/filename for the log to create> /I <fully qualified path to the msi you want to run in verboise logging mode>
Good Luck!
Robert
|
|
|
|
|
Thanks for your reply! I have been looking at the full log file off and on for several months, and I don't see anything in there explaining my problems, especially why the Uninstall custom action sometimes doesn't run.
|
|
|
|
|
Do you think our deployment projects have anything in common besides the obvious (.NET, etc.)? Is there some way we could work together on solving this?
|
|
|
|
|
Actually mine was very simple.
I'm sure you've seen the MSDN walkthroughs on how to create a custom action to compile NET assemblies into Native Images on the target machine. Well when that happens it adds an entry for each native image into a system table (you can view the list with ngen /L command I think.)
All I was trying to accomplish was creating a "well behaved setup" that would remove any Native Image entries it created using the Uninstall event.
It was a while back and I don't really remember much. I do remember that it should have been simple, but I never got it to work, and got tired of messing with it. 
I came to the conclusion that the Installer class worked fine for Install actions, but because I had problems getting even a simple uninstall action to run, I pretty much decided to abandon using them.
I think that until I can afford to get InstallShield, I'll go with creating a C++ dll to run any sort custom actions and just manually edit the Action tables in the msi to make sure my uninstall action calls in a DLL are made during an uninstall before the dll itself is removed.
There are some other things I don't like about the msi packages created with the NET IDE anyway, so I've devoted more time to learning about manually creating entire installs using Orca rather than digging any further into the Installer class.
Sorry ...
Robert
|
|
|
|
|
Ah, okay. Well, I think most of my critical woes are gone now. I was trying to register assemblies in a custom action, and that was a bad idea, so I let the MSI handle the registration. I still notice that the MSI doesn't seem to delete some registry entries that it added, and perhaps sometimes the Uninstall custom action isn't called, but that's more of a matter of tidying up the registry than something critical.
(I try to clean up the Registry after myself, but it's not my fault if the MSI sometimes can't be bothered to do it.)
Thanks!
Arun
|
|
|
|
|
Yes. I try for clean uninstalls, but at some point sometimes you have to just let it go.
I've never seen a Microsoft product itself that said it was logo certified????
And some of their setups are pretty bad.
When they released the eval versions of SQL Server 2000, I got one and put it on my machine. It ruined my MSDE server, and I had to go in and do massive manual registry cleanups to get MSDE installed back on my machine and working properly.
Now I do registry backups before I install anything from Microsoft, LOL.
Robert
|
|
|
|
|
Pretty funny stuff! Sad but true...
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
