So I have Visual Studio 2013 (community edition) with Qt addin installed, Qt5 libraries (32bit), and I'm trying to create an executable that is independent of all development configurations (it may use static or shared libs, I don't really care at this point).
OS: Windows 7, x64.
For doing this I changed the Solution Confguration visual studio option from Debug to Release, and add all the necessary libs in Configuration Properties -> Linker -> Input -> Additional Dependencies. The application now starts only if I run it from visual IDE, If I try to start it from the generated .exe I got The application was unable to start correctly (0xc000007b) error.
I have searched and found that this error code indicates one of the following problems:
32-bit app tries to load a 64-bit DLL (not my case I think, Qt DLLs are 32bit (I have installed using this .exe: qt-opensource-windows-x86-msvc2013-5.5.0.), and I use some other .DLLs which are also 32bit).
There are some missing DLLs. (I did copy all the necessary Qt DLLs in the same folder with the final executable).
For checking what dependencies my app requires, I opened the .exe file with Dependency Walker application, this is what it shows me:
in this list were also Qt5Multimedia.dll and Qt5SerialPort.dll, I get rid of the errors by copying the .DLLs in the same folder with the .exe.
Any ideas how to solve this?
You should never do that operation manually unless the standard procedure completely fails. There is already standard tool for Qt Windows deploymend windeployqt.
It takes care about Qt DLL dependencies, makes a copy of platforms\qwindows.dll and also it makes a copy of libraries that you cannot detect with the Dependency Walker, since image plugins and some other are loaded at runtime.
You do not even need to have your Qt bin folder in your environment PATH. The simplest deployment:
copy built exe binary to a new folder
open cmd console in that folder
call windeployqt using its full path (if it is not in the system PATH) and provide your executable, for example:
c:\Qt\Qt5.5.1-vs2013-x64\5.5\msvc2013_64\bin\windeployqt.exe application.exe
As a result you have in that folder all needed Qt DLLs. Of course you can have also issues with MSVC redistributables, but those should be deployed separately and installed once per system.
The tool windeployqt has various options. It can also take care about deployment of qml related files.
Only some 3rd party libraries should be copied manually if they are used, for example OpenSSL.
Solution:
As I got deeper, I have found this answer, after doing what that answer indicates (I actually copied all the .DLLs located in \Qt5.5.0\5.5\msvc2013\bin to the folder where my .exe is located), the error message changed from The application was unable to start correctly (0xc000007b) to Application failed to start because it could not find or load the QT platform plugin “windows”.
Searching on web for more about this error, I have found from this answer that you also need the platforms folder in the same location with the .exe (which was located in Qt5.5.0\5.5\msvc2013\plugins path). After copying that folder, the application started without any problems!!!
Now I just need to delete all unnecessary .DLLs from my application folder (Dependency Walker does not offer very useful information about this), and all the deployment is done.
I have solved the problem in the same time as describing it, so I guess I will just leave this here, may help others that have the same problem.
I'm sure this question has come up before, but I can't seem to find an elegant solution.
I have a web application project with multiple configurations based on deployment environment (Test, QA, Production) along with web.config transforms for each environment. We are using a web deployment package to automatically create the .zip of the app which can be deployed via MSDeploy. It's easy enough to call the package target multiple times, each with a different configuration:
msbuild MyProject.csproj /t:Package /p:Configuration=QA
msbuild MyProject.csproj /t:Package /p:Configuration=Test
But this triggers a complete rebuild of the web project each time before packaging. I want to build once, then apply the web.config transforms, and create separate packages for each environment. Is there an easy way to accomplish this without forcing a complete rebuild for each environment?
Dupe of Build once and deploy to multiple environments with msdeploy & Visual Studio 2012
I've also been wanting a solution to this, but apparently there isn't any real COMPLETE MS solution that I know of. Visual Studio provides the following (as noted here):
Web.Config transformation
Parameterization
Vishal Joshi concluded with the following:
If you can know your environment settings during build time use
Web.Config transformation.
If you would want to create deployment package only once and then
enter the settings during install time then use Parameters.xml
What I would like to see, though, is have the best of both worlds. I want to "package" up a target having ALL the configuration transformations embedded. Therefore, when the IT guy runs the WebDeploy cmd file (that gets generated when you "package"), they can provide a switch of which environment configuration they want (i.e. Dev, Test, Stage, Prod, Release, etc). I don't believe there is a solution from MS out there that does that. :(
When using Visual Studio 2008, when I "Publish Web Site", the application builds correctly, but then I get a "Publish failed" message:
What possible reasons are there for this, and how can I prevent it?
I had the same issue. Nightmare to identify the problem, because the logs and outputs show no errors or failures. I simply get "Build: 39 succeeded" and "Publish: 1 failed".
I resolved the problem by systematically removing all NuGet packages one at a time (and removing code that references it) until I identified the offending one.
This takes a LONG time!
However, the answer for me was Microsoft.Net.Compilers.
No idea how I ended up with that in my project, but as soon as I removed that package, everything publishes fine again.
Edit - For what it's worth, this problem occurs on VS 2008, 2012 and 2015 but does not occur on 2017.
You can try this:
Perform precompilation against the web application.
Clear the target directory(virtual directory in IIS or physical file
folder) and deploy all the files (of the web application) into the target
directory.
In the output window you can check at which stage does the publish website
operation fail. For example, at the first stage, if there are some error
which will only occur at precompilation, that will cause the stage 1 fail.
Or some times if the target directory has something configured incorrectly.
Such as the IIS virtual dir is not set to the correct ASP.NET version or
some old files are locked and prevent them from being cleared. Mostly,
publish failed will be caused by IIS side configuration issue such as
authentication setting....
Source link
You can open the output window by pressing Ctrl+W, O.
Sometimes it's because you need to be running VS as Administrator to be able to write to the target directory.
Check the Output messages, they should help you solve the problem
I had to copy project to C:\a\ and than publish. I suspect problems with long path. Strange, but worked for me.
The conclusion is: Try another VS edition and see if that does it.
Here is what did it for me.
I have VS 2013 Pro and Visual Studio 2015 Community. I sort of use one or another to work on my MVC project and all was fine. Then all of the sudden VS 2013 could not publish though it would build just fine. There was no erros other than some silly ...code is not returned from all paths...
So when I open it in VS 2017 - it published the same project just fine. I am suspecting a compiling issue - because that was the stage it would fail at.
Hope that helps you save a bit of time.
Not sure if this happens in different versions of Visual Studio, but at least in 2015 Professional Edition, the problem arises when we try to update all Nuget packages from the solution using the Packages Manager.
As pointed out by #SimonGoldstone the issue is caused by the package "Microsoft.Net.Compilers". By default, the package gets added to the solution while creating a new web application. The default version 1.0.0 does not introduce any problems. I was able to keep testing with latest versions until 2.4.0 and everything works fine, but from 2.6.0 henceforth is when it all starts. If an update is strictly required, I would recommend updating the aforementioned package until version 2.4.0. After doing some research, seems that some bugs on later versions than 2.4.0 are introduced and not fixed on the long term. What is curious though, is how this problem gets included on Nuget with no basic quality control checkpoint.
There are many proposed solutions for this. I think they are overcomplicating the issue.
I found the following worked for me:
Locate the obj(Release or Debug) folder in your solution
Inside the Release or Debug folder delete the CONTENTS of the 'AspnetCompileMerge' folder
Now try and publish.
Make sure you empty the target folder (manually) before publishing. Sometimes vs cant delete a file which will result in a failed publish
After trying a Rebuild, having other Projects in my Solution able to publish correctly, and changing my publish location to the C: drive (locally attached) instead of pushing to a mapped network drive, I was still having an issue where the only error output said:
========== Build: 5 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========
========== Publish: 0 succeeded, 1 failed, 0 skipped ==========
My solution is targeting x86, but I think during a Git Merge, this project had it's profile switched to Any CPU. After creating an x86 profile for the project and having it match the target of the publish goal and of the active solution configuration, I was able to successfully publish again.
Check Project BIn directory. there must be a DLL of your page or control. which has to be recreated during publish. So exclude it or remove it
I ran into this same problem today and it was due to the Thumbs.db file that was created when I opened my images folder to look for an image. I deleted the file and the project deployed successfully. Hope this helps someone else in the same situation.
Delete publish profile and create another one . Worked for me
In my case, I was publishing to a directory in a mapped network drive, but the Output panel/window was indicating that the location didn't exist. The path was correct, and the drive was fully accessible. The problem resolved itself when I re-set the path to publish to in Visual Studio by using the ... button.
With me it was simple - the dist folder was locked. I unlocked it by an unlocker and the publishing resumed.
I have several user controls that are registered in the web.config, and have a ClassName in the .ascx file header. For normal builds everything works fine, but with a publish those class names were not recognized anymore. At some point I found out that the errors were not in my regular code files, but in copies in a temp directory for publishing.
I had "Precompile during publishing" turned on (to be found under Settings > File Publish Options). Turning that option off worked for me.
I had the same issue with VS2017 with a website project. Build worked, but publish gave me an error:
Error CS0012: The type 'System.Net.Http.HttpMessageHandler' is defined in an assembly that is not referenced. You must add a reference to assembly 'System.Net.Http, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'.
All my projects already had a reference to System.Net.Http so it was really confusing.
To fix it, I had to copy System.Net.Http.dll into my website project / bin folder so publish could find it and copy it to my web host. I found System.Net.Http.dll by looking at another project's references (a class library), then System.Net.Http.dll Properties, and seeing the path (C:\Program Files(x86)\Reference Assemblies\Microsoft\Framework.NetFramework\v4.6\System.Net.Http.dll).
i know iam late but i think it should use for someone whos searching for this query.
just uninstall all your nuget pakages , then clean and rebuilt solution ,
now click on publish , sure it works and u will see publishing starts and works correctly now
If any one had changed the version of the project file and related framework. then this type of issue happened.
please go to "C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\MSBuild\Microsoft\VisualStudio\v16.0\Web" location for visual studio published and build setting -> edit -> comment the force copy of all file section.
I had one file that was not found. I had copied in a png file to replace a jpg in the content folder , same name except filetype extension.
Project built fine, but refused to build and publish . changed extension of file so it could find that file name and it worked - no errors amazing 1 thing wrong and everything else is an error.
The case for me was that Visual Studio was not signed in to Azure, but provided no indication of that. I edited the publish profile, clicked "Validate Connection" then clicked "Save" and then it worked.
I was working on a feature branch, which was failing. Switched to Master Branch, deleted the feature one and created another one. It worked.
What caused my issue was a little different, but has similarities to some of the reasons stated above.
I managed to trash my local copy of a given application and did a GIT hard reset to get the most recent from the repository in question. This in turn, wiped out the web.config file (which was not stored in the GIT repository for various reasons).
This cause configuration information for various NuGet packages to be "lost" (since it was stored in web.config).
Fortunately, I had "backed up" the web.config, so once I figured out it was not out there (a migration failed because I was unable to connect to the database), I was able to replace it.
Tried the publish again, after fixing the web.config, and everything worked perfectly.
If you are opting for the "Delete all existing files prior to publish" in the publish web dialog box, then make sure that the Visual Studio is started with Admin rights. Right click the Visual Studio and click Run as Administrator. Hope this helps.
Now that native code can have assemblies (e.g. "unmanaged assembly") for side-by-side cache usage, I'm interested in changing the version of a DLL after it is built (as part of an incremental build auto-versioning scheme). I think I'm close using this commmand:
mt -updateresource:MyNewlyBuiltThing.dll;#2 -identity:"MyNewlyBuiltThing, version=5.5.0.1"
That command gives me the following error:
mt.exe : general error c101008d: Failed to write the updated manifest to the resource of file "MyNewlyBuiltThing.dll". Access is denied.
That command is executed from a command prompt with administrator privileges, and I have no anti-virus software on my development box (and the file does not have a read-only flag set).
Perhaps the problem is that I'm using the wrong name in the identity string. After all, when I load the embedded resource of the binary into Visual Studio, it shows a manifest that doesn't bother to mention its name - it only mentions the names of dependencies.
Anyway, I was just wondering if the mt.exe could be coaxed into giving me the post-build version-bumping of a non-managed assembly. Any insight of what I'm doing wrong? And if this is not possible, why?
If permissions issues have been ruled out:
Are you running on a FAT filesystem? There may be issues if not on NTFS. Also, several issues of this type are gone with the latest mt.exe, part of the "Microsoft Windows SDK for Windows 7 and .NET Framework 4", version 7.1 so you could try that.
This one’s a head scratcher. Here’s the deal.
While deploying a beta copy of an ASP.NET application built with Delphi 2007 for .NET to a test server I encountered an odd problem. The application was unable to start because it could not load the correct version of an ADO.NET data provider that I was using.
Only by including a version of the old assembly in the bin directory would the application run. However, I don’t want to be tied to this older .NET data provider, so I am determined to find a solution to this problem.
I originally compiled the project with the .net data provider assembly used as Copy Local, which should have caused Delphi to use a copy of that version of the assembly that I selected when I added it to the References folder in the Project Manager. The actual assembly that I selected was version 9.10.2.0, and that is the version of the assembly that appears in the bin directory, along with the application. However, at runtime the application was trying to bind to an earlier version of the same assembly, 9.0.2.7.
(Actually, this problem occurs whether or not I use the GAC version of Copy Local, so I don’t think this is the issue.)
While investigating this problem I created a new project, and added a reference to the 9.10.2.0 assembly. Still, both the .NET 2.0 Configuration Utility and Reflector showed that the application compiled with a reference to the 9.0.2.7 assembly.
Inspecting the GAC I saw that both 9.0.2.7 and 9.10.2.0 versions were registered. Attempting to remove the 9.0.2.7 version fails, since that version of the provider was still referencing the assembly in the GAC.
I went into the registry and manually removed all references to the 9.0.2.7 provider. I then was able to delete it from the GAC. This didn’t change anything. Removing the assembly from an existing application and then adding the 9.10.2.0 version back, then compiling, still resulted in the wrong assembly information being inserted into the application. As before, creating a new application that referenced the 9.10.2.0 assembly didn’t work, as a reference to 9.0.2.7 was still being inserted into the executable.
I’ve checked the Delphi library search path. I also removed every instance of the old assembly files from the machine altogether (including from the ASP.NET Temporary Files directory). I still got the problem. I tried using Issam Ali’s AppManifest utility to manually adjust the manifest, but apparently it does not support ASP.NET applications in Delphi 2007 for .NET.
So, the GAC no longer contains references to 9.0.2.7, there are no references to it in the registry, there are no paths to the old provider directory in the project or Delphi options dialogs, the old provider assembly is not on the file system, and 9.0.2.7 does not appear in any of the project files. Nor does it appear in web.config, machine.config, or any other file I checked. Nonetheless, Delphi insists on using this version of the assembly anytime I reference the 9.10.2.0 version of the assembly. (Yes, I restarted Delphi, and also restarted the Virtual Machine in which this development was being performed.)
Even after uninstalling the 9.10.2.0 data provider (the older one was already uninstalled), and reinstalling it, adding the data provider reference to an application results in the runtime application attempting to load the old provider (even though no reference to the old provider apparently remains in the system).
I’ve tried other solutions (which are worth mentioning here), but none worked. Anybody seen this? I am going to continue working on this problem, but I’d love to hear suggestions. I just can’t get Delphi to stop inserting the old assembly information into the project.
For grins I’m including the error log from the failure. This log essentially duplicates the information I get from the fusion log. This log is from one of the simple apps I created after removing the 9.0.2.7 assembly from the GAC. Notice that it’s looking for the old version of the provider from the outset.
Assembly manager loaded from: c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\mscorwks.dll
Running under executable c:\windows\microsoft.net\framework\v2.0.50727\aspnet_wp.exe
--- A detailed error log follows.
=== Pre-bind state information ===
LOG: User = TRAINING8A\ASPNET
LOG: DisplayName = Advantage.Data.Provider, Version=9.0.2.7, Culture=neutral, PublicKeyToken=e33137c86a38dc06
(Fully-specified)
LOG: Appbase = file:///C:/Inetpub/wwwroot/TestAdsVer2/
LOG: Initial PrivatePath = C:\Inetpub\wwwroot\TestAdsVer2\bin
Calling assembly : TestAdsVer2, Version=1.0.3572.17384, Culture=neutral, PublicKeyToken=null.
LOG: This bind starts in default load context.
LOG: Using application configuration file: C:\Inetpub\wwwroot\TestAdsVer2\web.config
LOG: Using host configuration file: c:\windows\microsoft.net\framework\v2.0.50727\aspnet.config
LOG: Using machine configuration file from c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\config\machine.config.
LOG: Post-policy reference: Advantage.Data.Provider, Version=9.0.2.7, Culture=neutral, PublicKeyToken=e33137c86a38dc06
LOG: Attempting download of new URL file:///c:/WINDOWS/Microsoft.NET/Framework/v2.0.50727/Temporary ASP.NET Files/testadsver2/07545aea/3d068a5/Advantage.Data.Provider.DLL.
LOG: Attempting download of new URL file:///c:/WINDOWS/Microsoft.NET/Framework/v2.0.50727/Temporary ASP.NET Files/testadsver2/07545aea/3d068a5/Advantage.Data.Provider/Advantage.Data.Provider.DLL.
LOG: Attempting download of new URL file:///C:/Inetpub/wwwroot/TestAdsVer2/bin/Advantage.Data.Provider.DLL.
WRN: Comparing the assembly name resulted in the mismatch: Minor Version
ERR: Failed to complete setup of assembly (hr = 0x80131040). Probing terminated
This has gone on so long that the comments that I added to LanceSC's answer are no longer showing. But I do thing this is an interesting item that I want to address.
Here's my last two comments to LanceSC
The installation that exhibited this behavior is in a VM that is no longer functioning. Another developer I know experienced this same problem. The solution was to abandon the installation. I feel that something in the installer of the particular version of this .NET data provider left some strange artifact that produced the problem. It does not happen with any other build of this data provider. I am no longer pursuing an answer to this question.
Spoke too soon. A colleague of mine, today (March 5, 2010), encountered this same error, with a slightly earlier version of this same .NET data provider (9.0.2.1). He is now in the same position I was. He cannot run his application with any version of the data provider, save the old one. That assembly was being used as a local copy, and the old version is not in the gac. Using his machine, we ran the run MSBuild with the verbose option. The build worked fine with no errors. Nonetheless, the compile application failed to run, having failed to find the old version of the provider.
Summary
My colleague resigned himself to reinstalling Delphi 2007 (fortunately, he was working in a VM, and had a second VM with Delphi 2007 in which the offending .NET data provider had never been installed. This was also my tactic.
At this point, I have concluded that this problem is not solvable. Nonetheless, I am leaving this question open for another week or so. If no feasible solution is proposed in the next few weeks, I will close this question.
In the meantime, I have asked my colleague to preserve the VM with the misbehaving provider, in order to test any solution or investigation that is proposed.
Delphi 2007 uses MSBuild to perform the actual builds; however, the code in their product that syncs changes between the IDE and MSBuild is very brittle. My suspicion is that the build files are out of sync with the IDE. An easy way to update them is as follow:
Open your registry editor go to
HKEY_LOCAL_MACHINE\SOFTWARE\Borland\BDS\5.0\Globals
Change the value of ForceEnvOptionsUpdate to 1.
Open the RAD Studio IDE.
In order to confirm my suspicion you need to locate the files that Delphi.NET feeds to MSBuild. They are located somewhere under the current user's profile. You may also want to look at options in the Delphi help to have it do a verbose MSBuild output.
Have you tried grep'ing the Delphi and .NET framework directories for 9.0.2.7 to see if it is in a config file somewhere?
Something like:
grep -d 9\.0\.2\.7 *.xml
Other places you might search:
search the project files for 9.0.2.7
registry search for 9.0.2.7, and a search using the public token
If this app uses the BDP you might also search the BDP config files
I ran into something very much like this, and it drove me absolutely up the wall for days. I had a reference to Oracle.DataAccess.dll that was resolutely stuck pointing at an old version, regardless of what was in the GAC, in the search path, etc. No amount of restarts of modifications to the .dproj files would ever work.
What I eventually found was that the offending piece that was holding on to the old reference was the generated Oracle.DataAccess.dcpil in the C:\Users\Public\documents\rad studio\5.0\dcp directory.
It was over a year old - whatever the case was, Delphi did not want to write over it.
Once I deleted it, Delphi merrily created another one, and sure enough, it now points to the assembly I want it to.
Ugh, frustrating!