I got a problem with some ressources. I got a simple .exe file, that is accessed by my application. So I saved the exe tool within my project folder and everything was simple. But now I want the exe to be embedded inside my application, to keep everything nice and clean.
I want my app to be a single file executable, that will deploy its dependencies and stuff on its own.
So read a little tutorial on stack: How to embed dll from "class project" into my project in vb.net
I got the .exe into my ressources and pasted the code into my ApplicationEvents.vb (don't kill me for CP ;) ). Next I tried to execute the whole thing, but nothing happend. By executing the application step by step (F8), I saw, that the AddHandler call is executed, but the Deploy Function gets never called.
Next I read a tutorial at MSDN:
https://msdn.microsoft.com/en-us/library/vstudio/e2c9s1d7%28v=vs.100%29.aspx
I tried to change the persitence mode of my ressource as described, but the Persistance option is disabled.
So what can I do to deploy my second .exe?
Related
I have 2 programs which share a project in which an API DLL is used to perform actions on files in another directory. The problem that I have is that this code works in one project, but in the other it fails:
moduleHandle = LoadLibrary(“api.dll”)
Earlier on, the program that fails failed to connect to the API DLL here so after comparing the Process Monitor logs of both I copied some DLLs into the same directory as it. It then succeeded, and the values of moduleHandle are now the same in both programs. Next:
methodPointer = GetProcAddress(moduleHandle, "NameOfSomeFunction")
delegateForSomeFunction = Marshal.GetDelegateForFunctionPointer(methodPointer, GetType(SomeFunctionType))
When we get to the delegateForSomeFunction, I can see that the value of _methodPtr in them is different from one program to another. Then when we get to invoking the delegate:
Dim argsArray() As Object = New Object() {directoryPath, errorFilePath}
Dim retVal As Short = delegateForSomeFunction.DynamicInvoke(argsArray)
In one program this just fails silently. I'm at a bit of a loss as to how to proceed. What should I do to investigate this further and how can I get it to work?
I’m running this on debug in Visual Studio 2013, and the project is in .NET 4.
Although copying the correct versions of dependencies from winsxs into the same directory of the API DLL did allow me to perform LoadLibrary without obvious errors, it caused more errors in the background.
The problem was in the manifest in the end. There was a post-build event that removed the manifest from the .exe in preparation for a deployment step that allowed you to specify different versions of the API present. Creating a proper appname.exe.manifest file specifying the dependent assemblies that I was failing to load normally, and then placing this into the same directory as the .exe, solved the issue.
We are working on a validation script for Kofax Capture 9.0 / 10.0 in VB.NET 3.5.
We know how to create a script using the Admin Module, and how to get it operational.
The problem is that we need to reference a dll, located on a remote machine. (GAC is no option) This dll holds abstract classes we need in each validation script.
Even when putting the dlls locally (copy local), the Validation Module (index.exe) immediately throws the "cannot find reference" exception, even though the project compiled perfectly.
I guess the basic question comes down to: where do we put the dlls, in order for the Validation Module to find them?
The simple answer is to put the dll in the same folder as the application because this is one of the places which .NET will probe when trying to find it. The Validation module is run from the Capture bin directory which will be something like "C:\Program Files (x86)\Kofax\CaptureSS\ServLib\Bin\". This would need to be done on each client using Validation.
If you have a more complicated scenario, you could look implementing the AppDomain.AssemblyResolve Event and using Assembly.LoadFile to get the assembly from a custom location, but the using the bin path is less complicated.
If you end up having further trouble, you can troubleshoot by using the Assembly Binding Log Viewer (Fuslogvw.exe) which can tell you more details about why the assembly failed to load and where .NET tried to search for it. Assembly loading can fail for reasons other than just the path.
For more detail on how .NET loads assemblies, see the following:
How the Runtime Locates Assemblies
Locating the Assembly through Codebases or Probing
We found a solution: add all library files as "links" to the project. (Add --> Existing File --> small arrow next to "Add" --> Add as Link)
This ensures the files are compiled when you build the project. The Kofax Validation Module can now find the files, whereas when referencing the file, it could not. Why it could not, remains a mystery...
I am using Burn for MSIs package. I am using Votive (Visual Studio) & my own custom BA instead of WiXBA. I tried to debug custom BA using Debugger.Launch(). But when I start debugging, error messages occur.
No symbols are loaded for any call stack frame. The source code cannot be displayed
I realized that package.exe links CustomBA dll which located at C:\Documents and Settings\user\Local Settings\Temp\{GUID}\. {GUID} is always changed. So, whenever I run package.exe, always directory is changed.
I think that is the reason to occur errors.
In Visual Studio, When I started package.exe with CustomBA dll which located at absolute path (.../Debug/bin/CustomBA.dll). But after execute the package.exe, it links to Local Settings\Temp\{GUID} directory. So, when we start debugging and attached to CustomBA dll, CustomBA dll's directory is dynamically changed and No symbols are loaded error occurs.
Why package.exe links dll which located at C:\Documents and
Settings\user\Local Settings\Temp\{GUID}\? Can we choose the path
for dll statically?
If we can't choose the dll path statically, how can I use debugging
functions for CustomBA?
To debug a Bootstrapper Application, you'll want both your Bundle .wixproj and BA .csproj (or .vcxproj if you're doing a native .dll) in the same solution and the Bundle project should be dependent on the BA project so rebuilds work correctly. The following steps should allow you to step into your code.
Note: Ensure you are not running Visual Studio elevated. If you have UAC disabled, re-enable it. These steps will not work correctly if Visual Studio is running elevated.
Rebuild the project. This ensures you have a Bundle created with an updated BA.dll inside it.
Right click on the BA .csproj in Solution explorer and select Set as StartUp Project. The BA .csproj should be bold.
Right click on the BA .csproj and choose Properties.
On the Properties for the BA .csproj select the Debug tab.
In the Debug tab, choose the radio button labeled Start external program
Browse to the path where your Bundle is built.
Now, you can press F5 and start debugging. Remember that any time you change the BA .csproj, you also need to ensure the Bundle .wixproj is rebuilt. Otherwise, the Bundle will launch with your old BA in it and the debugger will find the newly built BA's .pdbs don't match.
Extra credit: if you disable Just My Code in the debugger settings and download the pdbs.zip and sources.zip for the matching build of your WiX install, you can actually step through the Burn code as well as your BA to see how everything works together.
I followed Rob's suggestion in this post but sadly i couldn't get it to work for me (Visual Studio 2015, Wix 3.10.3, managed Bootstrapper Application using WixWPF). No breakpoints are ever hit. I noticed the debugger attaches itself to the wrong process, the installer has two running processes (im guessing the BA and the Bundle). When I changed the process the breakpoints were hit but my managed BA has code i want to debug before the debugger actually gets attached
Ive managed to find a solution where the application will not start until the debugger is attached. I put this code in my constructors code-behind file (in the DEBUG block) for my managed BA like so...
public MainWindow()
{
#if DEBUG
// Do not start until debugger attached
while(!System.Diagnostics.Debugger.IsAttached)
{
System.Threading.Thread.Sleep(1000);
}
#endif
InitializeComponent();
InstallData = new InstallerInfo();
}
Now when i compile my managed Bootstrapper Application (with Debug) along with the Bundle and run it, the application will not start until you attach to the managed Bootstrapper Application Tools > Attach to Process > Find your exe in the list.
You cannot run your custom BA in debug mode from Visual Studio.
What you can do is to run the generated exe file and then attach Visual Studio to the process which would let you debug it. (In the menu: Tools > Attach to Process > Find your exe in the list)
As many other answers suggested above, the debugger is attached to the process that runs installer executables. You will need to manually attach the debugger to the UI process that is spawned under a temp folder like many have done before.
To allow for child processes to be attached automatically without all the extra code mentioned, you do can as mentioned:
Install the visual studio extension called MicrosoftChildProcessDebuggingPowerTool.
Set the executable in debug start action just like Rob mentioned.
Enable native code debugging (important)
Turn on Child Process Debugging by
Debug -> Other Debug Targets -> Child Process Debugging Settings -> Enable child process debugging -> Save
The only thing which really works is:
protected override void Run()
{
Debugger.Launch();
}
in your bootstrapper UI application (BootstrapperApplication descendant). Then start the built bootstrapper.exe from the explorer and reuse your Visual Studio instance in "Choose Just-In-Time Debugger" window.
Don't forget to clean the solution before re-building. This prevents sometimes from debugging correctly.
PS: when there are problems with finding the correct pdb's of your bootstrapper UI assembly, choose the same architecture than the bootstrapper setup. Mixing architectures can lead to debugging problems.
Cheers
Rob's solution doesn't work. Approach of AhmedBM works but it still can be further streamlined so that VS runs WiX bootstrapper process and then immediately attaches to the child process.
public void Run(EnvDTE80.DTE2 DTE, Microsoft.VisualStudio.Shell.Package package)
{
//kill old ones if any
System.Diagnostics.Process.Start(#"c:\Windows\System32\taskkill.exe", "/F /IM Bootstrapper.exe /T");
System.Threading.Thread.Sleep(1000);
//start new one
System.Diagnostics.Process.Start(#"<solution path>\src\Bootstrapper\bin\Debug\Bootstrapper.exe");
System.Threading.Thread.Sleep(1000);
foreach (Process proc in DTE.Debugger.LocalProcesses)
{
if (proc.Name.ToString().Contains(#".cr\Bootstrapper.exe"))
{
proc.Attach();
return;
}
}
System.Windows.MessageBox.Show("Bootstrapper Process was not found.");
}
The only problem is that you need DTE object. In earlier versions of VS we had Macroses where it was accessible. But in VS 2017 we don't have them. So, you can quickly make simple VS extension and add the command running the code there. Or use already existing extension, some of them allow to make custom commands.
Stick a MessageBox as the first line in your BA. Run the BA and the MessageBox will show up. Before hitting OK, From the menu DEBUG|Attach to Process, select your BA and Attach. Then hit the MessageBox's OK. Now your debugging!
Well suddenly when I’m trying to run my project from the debugger in Visual Studio 2010 It gives me this error:
Error 40 Unable to copy file "obj\x86\Debug\AssetsManagement.exe" to "bin\Debug\AssetsManagement.exe". The process cannot access the file 'bin\Debug\AssetsManagement.exe' because it is being used by another process.
Please is there someone how knows why that happens?
I have already delete the x86\Debug subfolder and te bin\Debug subfolder but nothing happen
Especially in the second folder the only file which cannot deleted was the the .exe file Also with the same error.
Most of the time when I see this error I go look in task manager and I see a VSHost file for my project running. You can't kill it, it just comes back. It's gotten to the point now I always uncheck enable visual studio hosting on the debug tab when I start a new project.
Try commenting out AssemblyVersion in AssemblyInfo.vb and performing a build.
Assembly: AssemblyVersion("1.0.0.0")
This has worked for me.
I've never had any problem with the basic gem tree structure, namely
bin (executables)
lib (source code)
test
...because I've always developed gems as libraries. However, I recently started to develop an application that ships as a gem.
This application has a "runner.rb" file (lib/mygem/runner.rb), that provides a method to run the application. The application is run from the bin/mygem file.
Now this bothers me. "runner.rb" is a file that is specific to our application, it is not a service or an API or any kind of support class for other to reuse (which is what library should be for, right?), yet its directory is "lib/mygem/runner.rb).
I've been reading a lot of definitions, and libraries are supposed to be support an application, not to be the application itself. We don't say "this is the library of my application", but "this is the source code of my application".
So my question is, why do we put the libraries AND source code in the same folder?
I hope I made my point clear, I'm sure there's a good reason behind this, and I'd be interested to hear your thought and to clear this out.
Thank you for reading this :)
After even further investigations, it turns out 'lib/' is called 'lib/' because it only contains definitions.
'bin' is a script that gets executed, like a 'main' function. Since it gets executed, no application logic should be in it, otherwise it's not easily testable.
Thus, all the application logic belongs to your application's library folder. The bin (main) file's only task is to instantiate your application's runner class and run it.