I'm not very experienced with deploying applications and i'm having an issue with my very small screen scrape application.
I use a project that handles all screen scrapes and i just call the functions from the dll(on dev machines at least). When i reference that dll from the directory, it works fine on my machine but installing and launching on another machine without the project crashes it immediately when it tries to access the class to instantiate the screen scrape object.
Perhaps my assumption of dll is incorrect but doesn't having the dll mean it incapsulates all the classes/references/etc in that project so it can be used elswhere without having to lug the whole project with it?
What could be going on with this dll?
The dll assembly encapsulates the project, but not its references. Anything that the project needs to reference must be available in the new environment as well, whether in the GAC (global assembly cache), the local directory, in a reference path, or wherever.
If you are using Visual Studio 2010 or earlier, you can use Setup Projects to nicely gather all necessary references and package them into an install package for you. There may still be complications that you will need to troubleshoot sometimes, but it simplifies your deployment effort. In Visual Studio 2012 and later, Setup Projects were dropped, but there are other options, like WIX and Install Shield. And that is a whole other topic with plenty of Q&A on this site.
Related
This is driving me crazy. I have developed a .NET COM DLL that is used by a VB6 DLL wrapper in order to update and replace some legacy functions in an application.
I am now trying to remove the requirement to use regasm on client machines so have worked out how to do that on a test DLL which all works fine.
I branched the DLL just in case and added an app.manifest file. Everything else worked out fine and I got it all working. The manifest is embedded and Visual Studio 2012 generates a mydll.dll.manifest file in the release folder.
Then I went back to the original trunk and added an app.manifest file (no point in merging as there were no code changes). I copied the contents of the branch into the app.manifest file and built the release version. The manifest is embedded in the DLL but no mydll.dll.manifest file is generated.
I know that it's not strictly necessary to have the mydll.dll.manifest file but I'd like things to be consistent (and for some reason the test process doesn't produce the same results with the trunk version) so how can I force it to be created?
This is a VB.NET DLL project so it doesn't have (or I can't find) the 'Generate Manifest' property drop down mentioned in the first answer here. How can I set this? Or is there a way to set it by editing the project file directly?
References:
Original walkthrough article and some corrections.
Overview by Junfeng Zhang in two articles plus a useful tool
You are making a fairly common mistake. A reg-free COM manifest helps an application find a COM server without looking in the registry to locate the DLL. Embedding the manifest in the DLL is like trying to solve the chicken and egg problem, Windows cannot possibly find that manifest if it cannot locate the DLL first.
The manifest needs to be part of the client app. Which is tricky since it is VB6, it doesn't support embedding manifests in its executables.
You could tinker with the mt.exe tool, an SDK utility that supports embedding manifests in an executable. You'd have to run it by hand after building the VB6 binaries. That's unfun and very likely to cause trouble when you forget. It is in general not a joyful tool to use, documentation is meager, incomplete and unhelpful, a chronic problem with manifests.
The fall back is a separate app.exe.manifest file, what Windows will look for next when it cannot find a manifest embedded in the executable. Where "app.exe" must be renamed to the name of the VB6 program. The EXE, not the DLL. This now also gives you a chance to avoid having to register the VB6 DLL, presumably what you really want if you truly want to make your program run reg-free. The disadvantage is that it will not work when you debug your VB6 program, wrong EXE. You'd also need a vb6.exe.manifest, located in the VB6 install directory.
Needless to say perhaps, very hard to get ahead with VB6 here. It just wasn't made to help you do this, they didn't have a time machine in 1998.
I have to admit that I don't know VB at all, but in the case of C++ and C# Visual Studio projects I previously had to resort to calling mt.exe in a post-build step in order to get the DLL manifest I wanted. Maybe that workaround would work in your case as well?
I am currently developing a Windows Store App that will eventually be targeted at the ARM devices when they are available. For now, I have been developing and testing from Visual Studio on my desktop computer and everything works fine. However, when I try to create an app package that I can pass along to others within my company for testing purposes, the application will not run properly.
The solution includes two projects. The first is a C++ project that is set to build a dll file. The purpose for this is to expose the Direct2D and DirectWrite libraries that seem to be unaccessible to a C# project. The second project is the C# project that references this dll for drawing functions and includes a XAML interface and most of the program logic. All of this works flawlessly on my development machine from within Visual Studio (and also when installing the package).
When I send the package files to other individuals within the company, the installation appears to work fine by installing with the PowerShell script. The tile appears in the start screen and the program will launch for a few seconds. The C# and XAML interface appears, but the DirectX portion of the application is not visible and the entire application shuts down within a few seconds. This makes me believe that the dll may not be installing or referenced correctly upon installation. I have checked the package file, and the dll file is included in the package after the build process is complete.
I have packaged a few different test programs (MSDN Samples) that have all installed on their machines, but we get the same results that they will not run (again, all samples run fine on my development machine when building them). The only test project that worked properly was a simple C# project that did not use DirectX at all. Any of the DirectX samples that I tried have all failed (including the native C++ samples that do not use C# at all).
To be clear, the process I use for building is going to Project -> Store -> Create App Packages and choosing the No option for uploading to the Windows Store.
Does anyone have any ideas on what might be going wrong with the build or installation process?
Thanks in advance for any help!
Does it work with the Metro Sideloader? I am not sure if it just adds a UI to the Powershell script, but it works for my team and me for testing...
Good luck!
Are you side loading a Debug version of your DirectX app onto a machine that does not have the Windows SDK installed? Visual Studio's default DirectX projects and the samples on MSDN both request the D3D11_CREATE_DEVICE_DEBUG flag when creating the D3D Device. Device creation will fail if the Windows SDK is not installed on the machine running the code.
Here are a few different options that will allow you to unblock yourself. Any one of these should give you the desired result:
Create a Release package and deploy that instead of a Debug package.
or - Go to DirectXBase.cpp and remove the D3D11_CREATE_DEVICE_DEBUG flag from the code.
or - Install the Remote Debugging tools for Visual Studio on the target machines. This will install the necessary SDK components to allow creation of D3D Debug devices. The other cool thing about this option is that once you're set up you won't have to create packages manually and side load them anymore. Just tell Visual Studio the name of your ARM machine and press F5 to deploy it remotely. More information here: http://msdn.microsoft.com/en-us/library/vstudio/bt727f1t.aspx
How are you deploying the native DLL with your project? Are you using project-to-project references? Can you verify that your DLL is ending up in the final package, in the root of the package application directory?
I recommend using Sysinternals Procmon to watch your application load on the target machine. If it crashes or fails, you can look in the log history for which DLL it is trying to load and failing. Typically this will show up as a repeated series of DLL load probes (it will try and load the dll from the application directory, and then proceed to try a number of other paths).
I developped a vb6 program then I build an installation wizard with visual studio interdev.
I used "dependency walker" and "process explorer" to find out the missing DLLs but there is always a problem with :
IESHIMS.DLL
WER.DLL
MPR.DLL
These dlls shown by dependency walker.
And when installing the program on another machine I have these error messages :
uxtheme.dll failed to register
msdatsrc.tlb failed to register etc..
PS : no problem on a machine where visual studio is installed.
Any Idea to fix this issue?
Thanks
Dependency Walker is not an appropriate tool to troubleshoot VB6 dependencies. It works well enough for DLLs written in C or C++ that use implicit dependencies. Although it hasn't kept up with the times and has trouble with DLLs that are stored in the Windows side-by-side cache or are delay loaded. Delay loading is what generates the warnings on ieshims.dll et al.
VB6 uses COM, which loads DLLs dynamically with LoadLibrary(). You'll never see such a dependency back in Depends unless you use the Profile option. Such DLLs are found back through the registry, the reason you needed to write an installer and tinker with regsvr32.exe.
You have to be pretty careful when writing installers like that, VB6 is old and can depend on operating system components that have been updated many times since 1998. Like uxtheme.dll, an important operating system DLL that implements visual styles. Having your installer overwrite the existing one on the user's machine is, well, disastrous. Although it is probably protected by Windows through its File System Protection feature, something that got added as a counter-measure against broken installers.
Giving proper advice is here difficult beyond "do no harm". A commercial installer like InstallShield or Wise (which I liked back then) is the best way to avoid shooting off the customer's leg. Fairly sure they still support VB6 installs. Microsoft makes a pre-cooked installer available for VB6 that installs all the core vb6 runtime components. You can download it here.
You should ALWAYS double check and verify any dependancies that you think your application needs.
All the files you mentioned are system DLLs and MUST NOT be distributed.
For a VB6 application you need the basic runtimes, and any DLLs you explicitly reference/use if and only if you have permission from the authors of those DLLs and instructions on the correct procedure and location for installing them.
For the standard Microsoft provided OCX files, these normally just need to be copied to the system32 folder and registered.
See redist.txt in the root of your Visual Studio installation for more details.
I have a seemingly random problem where my project will run using an old version of a DLL file that no longer exists. Sometimes the real version of the DLL file will be used, other times an ancient version of the DLL file will be used. Who knows where Visual Studio is getting this DLL file from - it's months out of date!
I know that it is using the old DLL file, because when the application runs I start getting weird 'TypeLoadExceptions', complaining that methods don't exist or don't have implementations.
The following actions will sometimes help, sometimes not:
Restarting Visual Studio
Restarting the computer
Cleaning and rebuilding the solution
Deleting everything in \WINDOWS\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files
Searching for and deleting instances of the DLL file in \Documents and Settings\username\Local Settings\Temp
Sometimes I perform all of the above steps, and it still uses an old copy of the DLL file. Where is it hiding it?!
The same issue exists on our TeamCity server which is using MSBuild. When TeamCity tries to run unit tests it uses an old DLL file.
Now, I know that I can use assembly redirection in the web.config file, but the version number of the DLL file hasn't changed (I don't bother to update it, so it just stays at version 1). I don't want to have to start versioning the DLL files just to solve this problem. I would just like to know which particular caches I need to clear so that I can get on with developing.
It hides it in the GAC. There it may reside indefinitely. Using a more recent version may indeed solve the problem, but there is an outstanding bug in Visual Studio that has to do with choosing the correct version of DLL files. (If DLL Hell wasn't bad enough, the Visual Studio team is making it worse!)
Finding it in the GAC is tricky, and I cannot advise you on how to do that, but once the old version is deleted from there, it will not be found again. Sometimes, even though you are pointing the compiler at a newer version (by date), it will use the older version, because it has the same version level (by version). That is its bug.
Who knows where Visual Studio is getting this dll from - it's months
out of date!
The Modules Window is your friend...
It'll tell you exactly where that file is coming from. You can even use it with arbitrary processes if you attach the debugger.
I too would guess that they're hiding in the GAC.
You can look in 'C:\Windows\assembly' to see all the dlls and unregister yours from there.
The problem may exists with the build order or your projects.
If your Test project is built before the application project, this cause the behaviour you describe. To fix this: right click on your main project in VS and select the Project Dependencies... option and check the build order. Changes to the build subsequence can be made here by correctly setting these dependencies.
I had a similiar problem (but without Visual Studio). I am loading a .NET dll using UnsafeLoadFrom.
On one computer (a terminal server) the old file still remains being used, regardless of updated version numbers, etc.
The reason is simple: As long as a program instance is running, which has already loaded the old dll, the new dll will never be used. All further UnsafeLoadFrom will become the old dll although the old version doesn't exist on the harddisk anymore, because it has already loaded some time ago.
The solution is to shut down all running instances of the application or even restart the computer. Then all new instances will get the updated dll.
In my case, this was caused switching to Release mode, which had a different configuration (that used different location of the DLL).
In my case, I use Visual Studio to Publish Website, and though I check the reference of the dll file has changed, but the published dll still is old. Finally I new a Publish Web Profile and choose the right configuration (such as Debug - x86 / Release - Any CPU), publish again then the dll is corrected.
While this question is old, maybe someone will stumble upon it again in his/her quest for finding a solution.
In my case i got a CS0433 error for an ASP.Net page. After deleting the content in the obj\ and bin\ folders of the project, it worked again. Probably has to be done with a closed Visual Studio. Maybe also clean out those folders in referenced projects in the same solution (if used in the project and not pulled via Nuget).
In my case, the old DLL was in
C:\Windows\Microsoft.NET\assembly\GAC_MSIL\MyDLL\MyDLL.dll
It DID NOT show up in c:\Windows\assembly.
I did a search of my drive for MyDLL, and it showed up as indicated above. I was debugging my test app at the time, and tried to delete the offending folder...no go...it was locked by Visual Studio. I had to stop debugging my app, close Visual Studio, and then delete the folder. Problem solved!! I don't know how my DLL got there, but it hasn't showed up there since I deleted it.
It's possible that the DLL is being referenced from another folder. It could even be on a network drive if you have one in your PATH environment variable. Here's how Windows searches for DLLs:
http://msdn.microsoft.com/en-us/library/7d83bc18%28v=vs.80%29.aspx
In My Visual Studio 2015, I ensured that the offending Visual Studio project's Reference Path Listing is empty:
If you find such problem ,delete your Reference dll and pdb extensionfile add new references and rebuild your project .This often happens due to no rebuild of project,commit and updates.
The fix for me was making sure that the virtual directory in IIS was pointing to the correct directory. I have two projects on my system, a v4 and a v5. The virtual directory on my dev system was pointing to the v4 bin directory instead of my v5 bin directory - oops!
The file that was being cached in the dll, I couldn't trace the file, so I ended up renaming the file. This might not resolve the problem mentioned here but this was the fix that worked for me related to this question.
I tried a ton of things including re-installing VS 2107.
You can see where the DLL files are being loaded from in your Output window. After going through all mine looking for project DLL, I found it.
Clearing this worked for me.
C:\Users\YourUser\AppData\Local\assembly\dl3\222Q4G1T.8AT\JBEAR7PB.E3J\8bfcf9ab\6e61cbd5_30acd401\YourDLL.dll'
I actually deleted all the files in:
C:\Users\YourUser\AppData\Local\assembly\
Holy Crow! I had an old, old suite of applications including 2 web services and a bunch of class libraries and a click once application. Well, click once stopped publishing for VS 2005 with a bunch of 'not found' errors. So, rather than hack away at my registry as suggested on this site, I figured it was time to upgrade the projects to 2017. Well, when I did this, the projects references in my web service projects got lost. Then, rather than helpfully just telling me that with errors, VS 2017 must have went to some cached file in C:\Users\XXX\AppData\Local\Temp\WebSitePublish or C:\Users\XXX\AppData\Local\Microsoft\VisualStudio\8.0\ProjectAssemblies or C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files\root and 'helpfully' just used those files instead! I had to do a hardcore search with a custom program to find all the files on my C:\ drive and delete them before I finally got the errors!
Is it possible to create a VB.Net application which users can just run without installing it first.
If not, is it possible in another .Net language.
If not, how IS it possible :)
PS: The application only has to run under Windows (>= XP).
If they have the .NET Framework installed (the version of it that you developed it), they only need the .exe. You can find the .exe file in the bin directory of your projects folder in your Visual Studio workspace.
If they do not have the framework installed, you'll need to produce an installation for them. It's extremely easy with Visual Studio by just creating a setup project in the same solution as your code.
As long as the user has the .net runtime installed, and your exe has any needed resources in the same folder (dll's, images, ect) theres no problem with that.
If you mean without installing the .net framework though, that won't be possible.
just build the program, and go into the (assuming the project name is app1) app1/app1/bin/debug/ dir. there should be a file there called app1.exe. this file is the compiled .exe from you project. any other computer will be able to run this without doing any installation (provided they have the .NET framework installed (it comes standard on any computer with an os > WinXP))
EDIT: If you were building with debug configuration, it would be app1/app1/bin/debug/, but if you were building with release configuration (which would probably be a better idea if you are distributing) the path would be app1/app1/bin/release/
If you mean running it without the .NET Framework, it used to be possible, but apparently the company's website is no longer in English so I have no idea what's happened to it.
EDIT: If you were building with debug configuration, it would be
app1/app1/bin/debug/, but if you were building with release
configuration (which would probably be a better idea if you are
distributing) the path would be app1/app1/bin/release/
I am developer and have no administration rights to live(production) network.
I had to find away to deploy an app without installation... and my app is self updating this cause other problems too....
The production network Computer check/monitors the file versions etc, so updating in the program files can not be done, where a MSI has been used for deployment.
Using this above I am able to copy and Run the App from the User Profile (where the user has full rights).
lets understand how program runs-
an .exe needs some function which are not inside the .exe, such as , for example substring() function. these predefined function resides in some .dll libraries.
when .exe is executed by user, .exe first finds the .dll and then the function inside that particular .dll.
.exe first looks within the current folder for that .dll
if not found then it searches that in PATHs. (PATH is Environment variable which value is a list of folders such as System32 etc.)
an .exe usually needs only 3 things - .exe itself, .dll which predefined function it is using, and some ActiveX controls(.ocx). apart from these 3, .exe only uses resources (such as icons etc).
lets focus on these 3(.exe, .dll, .ocx)
first you need to check what .dlls your .exe is using. you can easiely do this by using a dependency walker.
then make sure all these .dlls (that dependency walker is showing,or in other words- all these dlls whose functions your .exe needs) are either in current folder(in which your .exe resides) or in the PATHs.
if this step is done then your .exe has high chances to run whithout "installing".
the only problem is that some .dll and all of .ocx, needs to be registered first(means they have to have some kind of registry entry). they are not ready to use just by copying and pasting in current folder or PATHs.
but you can register these .dlls and .ocx's by using regsvr32 (with command line).
after that your .exe should not face any problem to run successfully.
hope you got the main concept.