I realise similar questions have previously been asked but nobody really seems to get to the bottom of it.
I am developing in a work environment where policy restrictions prevent users from installing software on their computers. I have created a VB project and am compiling the release to distribute but I just want a clean single .exe file, which I can put in a folder on a network drive and people can access at will.
Whenever I compile, I get the background files externally from the exe (vshost, config, manifest etc.).
My end users are not tech savvy, and are never really sure which file to open. Now, save creating a shortcut and hiding the program files away, is there another way of creating a single, rolled up, all-in-one, exe file for distribution?
You don't really need the other files (maybe only the .pdb depending on what kind of application you've made, and what code you use). Just copy the output .exe to the drive and it should be fine, IF it doesn't use any special dlls.
You need to add this code after registerign Form Close Event
private void Form1_FormClosed(object sender, FormClosedEventArgs e)
{
foreach (var name in System.IO.Directory.GetFiles(AppDomain.CurrentDomain.BaseDirectory))
{
if (name.Contains("manifest") || name.Contains(".pdb"))
System.IO.File.Delete(name);
}
}
You also need to close Visual Studio Window
Related
I have a com dll developed in VB.net that provides an interface to eBay api's. Been working for many years. Recently eBay change certificate authority and moved to TLS 1.2. Sorted through that but now the dll seems to quit in mid transaction when called from Access. The functionality does listings from local inventory to eBay. The first part loads pictures of the listing item to eBay. That works fine. I can see the calls and responses using Fiddler. It then moves on to actually listing the item which seems to stop when called from Access. What I get back in Access is "Can't find x.dll at file location". I know the call is going to the dll because it uploads the pictures.
I have a test project developed in VB.net to test the dll and when run from that everything works. I can see the listing call and response in fiddler. When run from Access there is no listing call. I can verify that the endpoints for the calls are the same from test project or Access.
My question is how to debug the dll in the Visual Studio IDE when it is called from Access. Any thoughts?
Yes, the way you do this is open up the vs class you have for the .dll.
Then in debug of the project, setup this:
Now, when you hit f5, then access will launch and run.
If at this point, say you close access (exit), then you note the debugging process stops.
However, go though the forms and whatever in Access, and get to the point where you hit that button or whatever.
You find now that you can say set a break point and even step and debug your .net code like any other code. So say in my example (a custom sage 300 .net interface to access), I want to debug "find customer" routine from VBA.
Well, in vb.net I have this code:
so, when any routine - even those in the class instances is called, you can set break-points etc.
And to stop? Just exit access.
So, you can make a change to your code, and even hit f5.
It not clear how you are registering your .dll (or do you use some VBA to side-load the .net - that's what I do, since it is a pain to have to register my .net com objects on each PC.
But, do give the above a try. It should let you debug your .dll code. The trick is to have VS launch ms-access as a attached debug session - and that is exactly what the above setting in your class project above allows you to do.
do note in above, I used the path to access 2010 (access 14), so replace the path name to the access.exe with your version of access you are using.
And keep in mind, that if have some installer, or some custom "thing" that registers your .net .dll for you?
Well, during this process, if your VBA assumes a registered com object, then ensure you have this check box enabled:
On compile for the project settings, you thus want this option checked:
NOTE very careful, checking the above option does not change the code or anything at all - it ONLY does a regasum automatic for you, and this would of course re-register your existing .dll - which is what we want for debugging. After you done, do run your re-register of your .dll to switch back from the debug .dll that going to be in your current project bin folder to whatever you "regular" use on your PC.
FYI:
In MOST cases, I find this whole idea does NOT work unless you launch VS as administraor. So, make sure VS is being run as administraor for this to work.
I tend to just tap windows key, or even right click on your vs shortcut, and of course choose run as administraor.
This is so often required, you note that VS will EASY and quite CLEAR show you running in admin mode, and I quite much now always run VS this way.
You should see this:
I have a single command line windows executable that has many options built into this exe file.
Eg:
(It can take screenshot)
ToolGo.exe printscreen c:\temp\filename.jpg yyyymmdd
(It can show up)
ToolGo.exe showIP machineA
I want to write another command line application, possibly in .net , where it can embed/build a wrapper around this ToolGo.exe file into my application without the user be able to use the ToolGo.exe, and also users can only access one function of this main exe file.
In the example I want this other tool to access only the print screen function in this new exe file.
The new application will have this:
Tool2go.exe printscreen c:\temp\filename.jpg yyyymmdd
But if someone types the following, it will not work:
Tool2go.exe showIP machineA
Or
ToolGo.exe showIP machineA
Any ideas how I can write this code to do this in a .net command line application?
This is a multi-part question, so I'll just give the main part of the issue as the answer with suggestions on handling the rest.
You can embed a .exe into your program by clicking on Properties and navigating the the Resources section, and adding that .exe to it.
After that, it's just a matter of extracting it locally so you can pass your commands to it, and handle it's responses. (I'm not really aware of any way to do so w/out first extracting the. exe; the .exe itself needs to run somehow after all).
To extract the embedded .exe, you do this:
' Extract the MyProgram resource (i.e. your .exe)
Dim b() As Byte = My.Resources.MyProgram
' Write it to the user's Temp folder
File.WriteAllBytes(Environment.ExpandEnvironmentVariables("%TEMP%\MyProgram.exe"), b)
By extracting it to the user's Temp folder, you can pass it your commands, and since it's 'out of sight' the user probably won't even know it's there to directly use it themselves, unless they're a bit more advanced and visit their Temp folder often. You can slightly help to avoid this, but extracting the .exe when your program starts, and then deleting it when it exits, so it only exists on the user's system while your program is running.
As far as what the user can and cannot type in order to pass to the program, you can simply handle the filtering with your program; since your program is the one passing the commands to the .exe, just don't pass any commands that you don't allowed, and pass the ones you do want allowed.
I've been trying for a while now to get a reference file to be loaded externally to no avail.
To be specific I am trying to load a "Microsoft Date and Time Picker Control 6.0(SP4)" which usually resides in C:\Windows\System32\MSCOMCT2.OCX
However some people that run a macro containing this element don't have that "MSCOMCT2.OCX" file on their PCs so I thought I will move the MSCOMCT2.OCX to a shared location and reference the code to use the shared one instead (so everyone will have access to it)
I tried doing that but when I was trying to load a reference with "Browse" from a different location it didn't load it - because I already had that in C:..
So I thought OK... I will remove the file from C:\ so I can only reference the shared file. - so I deleted it.
So I open the workbook again and look at references - I cant find "Microsotft Windows Common Controls-2.6.0(SP4)" - great!
And I proceed to add it manually with Browse from the shared drive.
When I do that however 2 references of "Microsotft Windows Common Controls-2.6.0(SP4)" are being added - 1 from C:\(which is not there) and 1 from the shared drive.
The one from C:\ is always automatically selected.
If I try to disable the one from C:\ and enable the one from the shared drive it automatically changes back to what it was when i press OK.
If I try to enable both - it says duplicate References and keeps only the one from C:\
So.. does anybody know how can I get rid of that C:\ reference from the list so it doesn't get loaded? Apparently deleting the files themselves did not work.
Ultimately my goal is to enable people without C:\Windows\System32\MSCOMCT2.OCX file to be able to use my Date Picker Tool.
Thanks a lot!
ActiveX control rereferences are always GUID-based. The VB IDE shows you the current location of the file as listed in the registry on your computer, as a courtesy, but it really doesn't matter what it says. The control will be loaded from wherever it was registered on the user's computer.
That's the key: the control must be registered on the user's computer.
I must strongly discourage you from doing what you're trying to do. You might be able to concoct a method by which you load the DLL from a network location, but it presents no advantage over doing the Right Thing(TM), and plenty of problems. The Right Thing is simply that if you need that control, you must distribute and register it with your application, just like everybody else does. And you really should install it in the recommended location for it (System32); not on the network.
Here's a quick example of what can go wrong: you provide your user with you app, and it works with the control on the network like you want it. Then the user installs another application that happens to need the same control. The app's installer sees that the control is already registered on the user's computer, so it doesn't try to add it again. Except that this particular app is intended to be used when the user is not connected to a network. Now you just broke someone else's program.
The VB/VBA architecture was never intended to support XCOPY deployment. I'm know it's a pain and that these extra steps are extremely inconvenient when you're just trying to deploy a "macro". Sadly, it's the nature of the beast. I'm sorry
Anybody know why the below error exist?
CrystalDecisions.CrystalReports.Engine.LoadSaveReportException: Load report failed
From your comments about windows\Temp, that is caused by the application pool's identity not having access to c:\windows\Temp (and possibly to the reports folder).
You can solve this problem by giving the application pool credentials that do have the necessary permissions, or giving read write permissions to "Network User" to the c:\windows\temp folder (and again, possibly to the reports folder).
The reason why this folder is required is that the crystal runtime creates a dynamic copy of the report at runtime and places it in the %temp% folder. It is the temp folder copy (with a GUID appended to the original file name) that is shown in the web browser. This is by design and is a useful feature to ensure the live report is safe.
Following from this, you will have to do a proper cleanup after loading every report because they just stay there and fill up the temp folder!
Something like:
CrystalReportViewer1.Dispose(); // if using the viewer
CrystalReportViewer1 = null;
report.Close(); // I can't remember if this is part of the reportDocument class
report.Dispose();
report = null;
GC.Collect(); // crazy but true. Monitor the temp folder to see the effect
Reckface's answer was clear enough, but to add something up.
I managed to get it working using this:
protected void Page_Unload(object sender, EventArgs e)
{
if (reportDocument != null)
{
reportDocument.Close();
reportDocument.Dispose();
crystalReportViewer1.Dispose();
}
}
Doing so may cause issues with the buttons on the toolbar, they can't find the document path anymore because the document is disposed. In that case the document needs to load the path again during postbacks: source
This is a very old question, but I want to add that I got this error because the report was not embedded into the class library.
Solution: I removed the report from the project. I restarted Visual Studio 2022 and than added the crystal report again. This time it was added as an embedded resource.
Did you even bother to Google it? This is a common exception; there are hundreds of posts about it scattered around the intertubes.
The Crystal .NET runtime has famously cryptic error messages. This one just means that the .rpt file (or embedded report) could not be loaded. There are several possible root causes: wrong filename or path, security violation, you are not disposing of old reports properly and windows/temp is getting hogged up, etc.
Do some research. If you're still stuck, come back and elaborate on the problem (do any of your reports work, is this a web app?, what code are you using, etc.)
I'm creating a self updating app where I have the majority of the code in a seperate DLL. It's command line and will eventually be run on Mono. I'm just trying to get this code to work in C# on windows at the command line.
How can I create a c# application that I can delete a supporting dll while its running?
AppDomain domain = AppDomain.CreateDomain("MyDomain");
ObjectHandle instance = domain.CreateInstance( "VersionUpdater.Core", "VersionUpdater.Core.VersionInfo");
object unwrap = instance.Unwrap();
Console.WriteLine(((ICommand)unwrap).Run());
AppDomain.Unload(domain);
Console.ReadLine();
at the ReadLine the VersionUpdater.Core.dll is still locked from deletion
The ICommand interface is in VersionUpdater.Common.dll which is referenced by both the Commandline app and VersionUpdater.Core.dll
The only way I've ever managed something similar is to have the DLL in a separate AppDomain to the assembly that is trying to delete it. I unload the other AppDomain and then delete the DLL from disk.
If you're looking for a way to perform the update, off the top of my head I would go for a stub exe that spawns the real AppDomain. Then, when that stub exe detects an update is to be applied, it quits the other AppDomain and then does the update magic.
EDIT: The updater cannot share DLLs with the thing it is updating, otherwise it will lock those DLLs and therefore prevent them from being deleted. I suspect this is why you still get an exception. The updater has to be standalone and not reliant on anything that the other AppDomain uses, and vice versa.
Unwrap will load the assembly of the object's type into the appdomain that calls it. One way around this is to create a type in your "base" assembly that calls command.run, then load that into your new appdomain. This way you never have to call unwrap on an object from a type in a different assembly, and you can delete the assembly on disk.
When I built a self-updating app, I used the stub idea, but the stub was the app itself.
The app would start, look for updates. If it found an update, it would download a copy of the new app to temp storage, and then start it up (System.Diagnostics.Process.Start()) using a command-line option that said "you are being updated". Then the original exe exits.
The spawned exe starts up, sees that it is an update, and copies itself to the original app directory. It then starts the app from that new location. Then the spawned exe ends.
The newly started exe from the original app install location starts up - sees the temp file and deletes it. Then resumes normal execution.
You can always use MOVEFILE_DELAY_UNTIL_REBOOT to delete on reboot. This is most likely the least hackey way todo this sort of thing, by hackey I ususally see things like; loading up new DLL's or injecting to explorer.exe even patching a system dll to get loaded into another process, etc...
MoveFileEx From MSDN;
lpNewFileName [in, optional] The new
name of the file or directory on the
local computer.
When moving a file, the destination
can be on a different file system or
volume. If the destination is on
another drive, you must set the
MOVEFILE_COPY_ALLOWED flag in dwFlags.
When moving a directory, the
destination must be on the same drive.
If dwFlags specifies
MOVEFILE_DELAY_UNTIL_REBOOT and
lpNewFileName is NULL, MoveFileEx
registers the lpExistingFileName file
to be deleted when the system
restarts. If lpExistingFileName refers
to a directory, the system removes the
directory at restart only if the
directory is empty.