|
Almost.
Dim Message as String = "Selamat Programming!"
...
DML.Parameters.AddWithValue("@Message", Message);
|
|
|
|
|
I want to ask, the difference between the insert into TBlSMSMasuk (Nim, Name, Date, NO_Telepon, Message, Status) Values (@ Nim, @ Name, @ Date, @ NO_Telepon, @ Message, @ Status) and "insert into TBlSMSMasuk (Nim, Name, Date, NO_Telepon, Message, Status) values ('"+ Nim +"', '"+ name +"', '"+ Date +"', '"+ NO_Telepon +"', '"+ message +" ',' "+ status +" ') ", what is it,?
|
|
|
|
|
I added the ionic.dll file in my solution's bin and then added a new folder with the name zipmyfiles.There is a compile time error which i am not able to find a solution. please help me out.
Compiler Error Message: CS1061: 'ASP.about_aspx' does not contain a definition for 'btnZipFile_Click' and no extension method 'btnZipFile_Click' accepting a first argument of type 'ASP.about_aspx' could be found (are you missing a using directive or an assembly reference?)
|
|
|
|
|
Member 10175264 wrote: are you missing a using directive or an assembly reference?
You do not have a declaration for btnZipFile_Click in your code.
Use the best guess
|
|
|
|
|
Hello could anybody Help me about passing the value of a textbox from form using Ajax Actionlink. It's been whole day figuring out still I'm getting value of null.
Im using pure Ajax Action link with out Any button.
here is the sample of delete ajax action link works perfect!
http:
But using it in form collection the value always null. Any help Appreciated Thanks!
here is my code:
CustomerVIEW
<% using (Html.BeginForm())
{ %>
<%= Html.TextBoxFor(model => model.Fname, new { id = "Fname" })%>
<%= Html.TextBoxFor(model => model.Lname, new { id = "Lname"})%>
<%= Ajax.ActionLink("Create", "Create",
new { id = 1},
new AjaxOptions {
HttpMethod="POST",
OnFailure = "function() { alert('fail'); }",
OnSuccess = "function() { alert('success'); }"
})%>
}
------------------------------------------------------------------------
CustomerController
[AcceptVerbs(HttpVerbs.Post)]
public ActionResult Create(FormCollection formCollection)
{
clsCustomer objcustomer = new clsCustomer();
clsSession objSession = new clsSession();
objcustomer.Fname = formCollection["Fname"]; --> NULL
objcustomer.Lname = formCollection["Lname"]; --> NULL
}
|
|
|
|
|
You should try the ASP.NET forum.
Use the best guess
|
|
|
|
|
I am writing a windows application In VS2010.
I am mapping a webdav drive after successful login.
How Can i watch evens in that drive using c# evens?
Events may be renaming a text file in that drive.
FileSystemWatcher is working with normal drives but not with virtual drives.
Please help me with any solution
Regards
Anish
|
|
|
|
|
FileSystemWatcher works with UNC shares on Windows Servers. Without knowing what your code looks like and what the server is your drive is on, it's impossible to tell you what's wrong with any accuracy.
|
|
|
|
|
I want to create upload file to the server drive c. But there is user credentials require to access the server file path. So i use this code in app.config
<configuration>
....
<appSettings>
<add key="DocumentVault" value="\\10.100.100.10\C$\SomePath\SomeWhere\Else\"/>
</appSettings>
....
</configuration>
How to add the user credentials inside?
|
|
|
|
|
Why are you using an Admin share, C$?? Why not just create a share directly on the target folder and set appropriate permissions for the user account(s) or group(s) you're using?
|
|
|
|
|
hueikar wrote: How to add the user credentials inside?
You can't add them to a UNC-path; by doing so, it's no longer a UNC-path. Your best option is to save them separately, and to connect from code[^].
(..and, as Dave remarked, it's not a very good idea to be storing the password of the local admin in a human-readable file!)
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
Hello all, first time posting here.
At my workplace, we have a requirement to ship a program with as little button pressing as possible. The users on the other end are factory workers and it's well known that if you give them an option, they will misuse it. Anyhow.. the program is going to be written in .NET with WPF. We have to work under the assumption that the machines do not have .NET installed and they can't install it.
Now before I ask the question, which is more of a general "what if", please note, I am not interested in anything but what I am about to ask. For example "oh just install this", or "Oh, not possible". After doing many hours of research, what I ask IS in fact possible, because commercial programs do this (spoon studio, boxed app).
I am an advanced developer, so I know my way into some scary places in the Win32 API and also have been developing in .NET / Win32 / C++ for many years. My current job (past year) has been mainly with embedded C, so I am just getting back to Win32 stuff heavily.
So the subject of the question says it all. I want a standalone .NET exe in which the user does not have to install anything AND of which does not copy any temporary file to the file system. Using the commercial options (spoon studio / boxed app) are not possible, because they are not free, and this has to be a free solution for us.
So here is the meat of what I want to do. I want to make a CLR host that essentially calls into the mscoree.dll to host our .NET application pulling in all the dependencies that mscoree.dll needs. Where do these files come from if we cannot copy any temporary files you ask?: The Dll's are to be stored in the exe itself as resource files.
The Win32 loadlibrary function works only from files on the file system. However, after poking around with Win32 hooking, it has been discovered that LoadLibrary uses ZwOpenFile internally to get a handle to the file you pass in. ZwOpenFile can also not work with anything but a file system file that I am aware of.
Here is my idea. We hook ZwOpenFile using extended code overwriting. After disassembling NTDLL.dll, this is possible, because the prologue to the function is more than 5 bytes. Next, our custom function gets called. Thirdly, ZwOpenFile passes back a PHANDLE pointer to the opened file. How can we rejigger this PHANDLE pointer instead of using ZwOpenFile? How about CreateFile? Using CreateFile, you can pass in a named pipe. CreateFile returns a HANDLE pointer that I ASSume can be assigned to the ZwOpenFile PHANDLE parameter. I don't have a lot of experience with named pipes and what not, but this is just an idea. Maybe there is another way. Basically we get the dll file required by LoadLibrary from the resource stored in the exe originally. Using this block of memory, which is actually the dll itself, we can map it into something so that CreateFile gives us a handle that ZwOpenFile can pass back to LoadLibrary. Now, the big question is... is a file handle created with CreateFile 'compatible' with a PHANDLE that ZwOpenFile passes back. I am guessing that the structure is the same, BECAUSE I also tinkered with hooking the CreateFile API which uses ZwCreateFile internally. Thus, a PHANDLE from ZwCreateFile (which would give us a memory handle to the image instead of a required disk file) should be compatible with ZwOpenFile.
The mscoree.dll also requires some registry keys. I also looked at some registry key functions in a disassembler and it is also possible to hook these. However, I have not worked out the interaction of the registry keys and where they are used yet.
This is just my idea, but hopefully there are some constructive minds out there with more information on the subject. We really want the standalone .NET exe so that we can avoid writing a native Win32 program. PS, I am not interested in using anything other than .NET and WPF: no QT, no mono + GTK, no whatever, so please do not bring those options up.
I would treat this as more of a "what if" question besides trying to worry about what is happening with why I am asking the question.
Thanks
|
|
|
|
|
What you want is possible, but not a single app that can accomplish this is free.
LostTime77 wrote: ZwOpenFile can also not work with anything but a file system file that I am
aware of.
True. You just defeated your own "no temporary files" requirement.
LostTime77 wrote: Here is my idea. We hook ZwOpenFile using extended code overwriting. After
disassembling NTDLL.dll, this is possible, because the prologue to the function
is more than 5 bytes. Next, our custom function gets called. Thirdly, ZwOpenFile
passes back a PHANDLE pointer to the opened file. How can we rejigger this
PHANDLE pointer instead of using ZwOpenFile? How about CreateFile? Using
CreateFile, you can pass in a named pipe. CreateFile returns a HANDLE pointer
that I ASSume can be assigned to the ZwOpenFile PHANDLE parameter. I don't have
a lot of experience with named pipes and what not, but this is just an idea.
Maybe there is another way. Basically we get the dll file required by
LoadLibrary from the resource stored in the exe originally. Using this block of
memory, which is actually the dll itself, we can map it into something so that
CreateFile gives us a handle that ZwOpenFile can pass back to LoadLibrary. Now,
the big question is... is a file handle created with CreateFile 'compatible'
with a PHANDLE that ZwOpenFile passes back. I am guessing that the structure is
the same, BECAUSE I also tinkered with hooking the CreateFile API which uses
ZwCreateFile internally. Thus, a PHANDLE from ZwCreateFile (which would give us
a memory handle to the image instead of a required disk file) should be
compatible with ZwOpenFile.
Blah, blah, blah, ... you just got yourself into more work than it would be to write your own linker (remember the apps that are never free that do this!)
Really, think about this. You said it has to be free, but how much are you (and supposedly your team) is getting paid by the hour?? I'll be willing to bet that the cost of the linker is cheaper than the time it's going to take to build this off-the-wall solution, test the crap out of it before you ship it, and find out that certain parts of the .NET Framework will no longer work because it, like anything dependent upon Reflection for example.
You're not going to whip this up in a few hours. You're GOING to spend a lot of money on this no matter what route you decide to go.
Oh and, on the side, your resulting executable is going to weigh in at over 200MB, plus.
|
|
|
|
|
It is free. My company is spending no money on this solution. I am doing it on my own time as an experiment, because I am interested in proving people wrong, such as yourself. I honestly dislike all the people who try to hammer down others because they are afraid to try something outside the box that is unsupported.
Writing my own linker? Are you kidding me? For your information, I have already done that. Anyhow.. now that that is out of the way, this is nothing like writing one's own linker. This is hooking API calls. I suggest you read what that is before you go spouting nonsense, trying to compare linking and injecting some code into a dll file. I know the difference.
200MB plus? Spoken like one who apparently knows the size of all the dll files needed. Why don't you take a look at an article that the boxedapp people wrote a while back. I believe it is called "Boxedapp .NET redistributable" or something like that. In there, they give all the dll files needed for a standalone console app. I assure you, my friend, it is much less than 200MB. The dlls required in system32 are very lightweight. Kernel32.dll itself is around 1MB. Adding the dlls for WPF amounts to maybe 20MB. I gathered all the dlls that I was referencing from the GAC and checked.
|
|
|
|
|
Just an FYI. I found the article and I pulled in a little more than half the dlls required by that article just to get the clr to run and also all of the dlls for WPF (presentationcore, presentation framework, system.xaml, system.xml, windowsbase). I pulled in the major ones, such as clr.dll, mscoree, mscorlib, etc. which are huge. The rest of the dlls are just small native win32 dlls that need to be pulled in. 31.7MB. That's quite the far cry from 200MB. I just ran winrar on all the ones I pulled in and Ive got a package with a whopping 10 megabytes for that entire slew of dlls that just took up 31.7MB. Assuming you can unzip into RAM, which should be possible somehow, nothing is wrong with storing a zip in the exe.
|
|
|
|
|
CMurphy77 wrote: The rest of the dlls are just small native win32 dlls that need to be pulled in.
31.7MB. That's quite the far cry from 200MB.
I think you're forgetting the class library .DLL's.
|
|
|
|
|
Which .dll are you referring to? I did say that I didn't have everything in that metric; however, I got the major dlls which were very big. If you are referring to system.dll, I already have that. Either way, I expect maybe a 50MB file after all the files are included. Zip them up and you have a very small file as seen by me going from 31MB down to 10.
If you mean to tell me I need every class dll .NET has to offer, then yeah... the file would be very big. BUT, what makes you think I need to include those in the executable? -> because I don't. I only need to include the ones I am using.
|
|
|
|
|
CMurphy77 wrote: you mean to tell me I need every class dll .NET has to offer, then yeah...
Nope. But, you'll find out along the way which ones you're missing.
|
|
|
|
|
I might be able to relax my requirement of no files on the file system. After looking at how windows actually locates DLL files, it first looks in a known DLL directory (system32 for example). Then it looks in the directory that the process was executed from, etc.. What I am thinking is that if I just package all the required DLLs and plop them into the directory as hidden files or something, windows will be able to locate all the DLLs required for the runtime. Next, after peering into how the clr loads, we have some registry keys to sort out. Adding keys to the registry is very easy to do. As far as I can tell, the important key is the install location for .NET for the clr to load the .NET libraries it needs. We can point that to just about anywhere in the key.
So to summarize, We find all the required dll's via trial and error then we zip them up to make the resulting exe small. We package the zip as a resource. The exe itself will be a clr hosting shim. If the system does not have .NET X.X installed, we unzip the zip resource, copy those files to the local folder, and install the registry keys .NET requires. The program then just runs as if the .NET framework were installed. Of course, we can make the program fairly robust making sure all the known files are on disk, locking them while in use, etc. etc.. using the native C++ shim.
This seems like an extremely easy option to package our exe as a "standalone" exe. The resulting exe should not be very big either, considering the metric that I found earlier.
|
|
|
|
|
CMurphy77 wrote: This seems like an extremely easy option to package our exe as a "standalone"
exe
If it was that easy, why isn't everyone doing it?
Look. You're asking a question that nobody is going to be able to walk you through. This is going to take a ton of research on your part. If this is a hobby, great! You've got all the time in the world to work on it and I look forward to seeing an article on the technique.
But, you originated this as a business requirement for deployment, not a hobbyist question. That means you've more than like got a deadline. In all seriousness, I don't think you're going to figure this one out before then.
I'd love to help you, but I simply don't have the time to start a major research project like this.
|
|
|
|
|
There is no deadline on this as of yet. I would suggest you stop making assumptions. The actual starting point of this deployment is way down the road, not anywhere in the near future. You don't have to make it look like you care about any deadline that doesn't actually exist.
On that note, this is not a "hey do this for me". All I was intending was for constructive comments on the situation. I didn't ask for your help, nor do I want anyone to do this for me. As I said, I am experienced developer myself, therefore I can do things myself.
At this point, this is a hobbyist question.
Also at this point, friend, I have implemented the above test by pulling in all the required dll files into a folder and tricking windows into running .NET without it actually being installed. It's very simple. There are two things to note. One is the %windir% environment variable that gets passed into a process. You can start one process and then, without changing the variable, can start another process with a variable that is rejiggered. You can trick the runtime into using your path's instead of its own. Second is the registry key install path for .NET that has to be remapped.
I made a demo WPF application and ran it without .NET being installed. Now, before you try and say it's going to take a long time to do... It took me about 1 hour of probing and setting it up.
Have a nice day. This has been an exercise of proving an experienced developer incorrect.
|
|
|
|
|
I'm glad you had fun! Have a nice life!
|
|
|
|
|
Yeah, thanks for telling me nothing could be done. It really urged me to prove you wrong in a little over an hour. I really appreciate it.
|
|
|
|
|
I didn't say nothing could be done. You just shot me down at every turn.
Have fun being the new "big man on campus".
|
|
|
|
|
I shot YOU down? After I made my first post you spurted out a bunch of "blah blah blah" comments. All you have done this entire time is say "it will take too much time, dont reinvent the wheel, etc." You also incorrectly compared the type of hooking I wanted to do to writing a linker. I don't think so. Get your facts and your head on straight before telling me I shot you down.
This is why I tend to stay away from forums. I am a master of google and if I have to go onto a forum for constructive comments, it because there literally are no resources for what I am doing. I know it is fact that when I ask a question, some person just like yourself is waiting at every turn. You are an element of the system, nothing more or less.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
