I'm working on my second application in QT and i'm trying to deploy a rough copy for testing. It would not run on a test computer, runs with no problems on mine, giving the error "Procedure Entry Point _ZdaPVJ not found in QT5core.dll". So to make sure that was not my program messing things up, i created a blank test application, compile it for release, moved the test.exe to a different location, run windeployqt --release test.exe, it created all the dependencies and folders. clicked on test.exe run with no problem. grabbed the folder recently created took it to the other computer and go the same error.
Is there something that i have forgotten since i compile my first application? Did i changed some setup somewhere without realizing it?
frustrated...
Perhaps you can check if your problem is related to different versions of the dll existing on your system and the wrong one is being loaded:
QT Release build DLL procedure entry point error
https://forum.qt.io/topic/26707/the-procedure-entry-point-cound-not-be-located-in-the-dynamic-link-library
As is suggested in the latter link above (towards the bottom), you could try to use dependency walker to determine from where the dll is loaded. Or use static linking with the licensing issues that causes (also see the latter link above).
And throwing in a final link on using Qt's Window's Deployment tool: Qt deployment; the procedure entry point ... could not be located
i have to fight against a strange issue in my company. we have 2 .net 2.0 (old, i know) apps, which start with an .asmx-file. the code-behind calls a c#-file, which includes a include abcd directive, whereby abcd originates from a 3rd-party company.
one app is in test and it works fine. the identical one is in production and fails with the error Could not load file or assembly 'abcd.dll' or one of its dependencies. The specified module could not be found.
when i look in the related web.config-files, none of them includes a pointer to abcd.dll, which i first do not understand in the context of the productive environment, where everything works. secondly when i look inside the \bin-folder, i see the related assembly/dll. again: this is identical in both systems.
the only difference of both systems is the fact that visual studio 2.0 (does this really exist?) is available on the test system.
please note: i am aware that assemblies have to be added via solution explorer in visual studio too. but i cannot do this as such an installation is not allowed here. but again: in web.config on the test server no reference can be found in the related web.config and everythings works fine.
so my question is: how to get this thing working in productive env?
thanks in advance
You may want to run Dependency Walker (depends.exe) http://www.dependencywalker.com/ and point it at to detect if any dependencies are missing.
I'd also look in the GAC (C:\Windows\assembly) to see if there are any related differences there.
Also, compare IIS setting on the two machines.
After migrating from my old Macbook Pro to my new one, I find that my project will no longer run. Grails keeps giving me a "Error /Users/Michael/{proj}/{proj} does not appear to be part of a Grails application". Refresh dependencies does seem to run successfully.
I have verified the following:
there exists a folder grails-app in the project folder at the same location as on the old machine.
I did run a grails clean followed by a grails upgrade to 2.0.4
The one thing it could be is that the user directory name has changed between the two machines, but I do not see the old user directory name in either .project or application.properties or in any settings.
I solved this by deleting workspace\.metadata\.plugins\org.eclipse.debug.core\.launches\<project>.launch. It had cached the old absolute path.
Open the command line from within STS and executed a "run-app". There is sometime a problem with he workspace caches.
oops, saw that I had left this question unanswered.
The answer was to erase everything and rebuild from github. When in doubt, nuke it until it glows....
Armand's answer above was the simplest solution - thanks Armand
This has been my experience - when working with the Grails in the IDE - in certain cases it's better to use the command line to issue grails commands (this was a good reminder)
Related to this, it seems better to run-app from cmd line as well (as opposed to using the IDE Project->Run As), since you can just stop the server easily with ctrl-c
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.
As part of improvements to our build process, we are currently debating whether we should have separate project/solution files on our CI production environment from our local development environments.
The reason this has come about is because of reference problems we experienced in our previous project. On a frequent basis people would mistakenly add a reference to an assembly in the wrong location, which would mean it would work okay on their local environment, but might break on someone else's or on the build machine.
Also, the reference paths are in the csproj.user files which means these must be committed to source control, so everyone has to share these same settings.
So we are thinking about having separate projects and solutions on our CI server, so that when we do a build it uses these projects rather than local development ones.
It has obvious drawbacks such as an overhead to maintaining these separate files and the associated process that would need to be defined and followed, but it has benefits in that we would be in more control over EXACTLY what happens in the production environment.
What I haven't been able to find is anything on this subject - can't believe we are the only people to think about this - so all thoughts are welcome.
I know it's anachronistic. But the single best way I've found to handle the references issue is to have a folder mapped to a drive letter such as R: and then all projects build into or copy output into that folder also. Then all references are R:\SomeFile.dll etc. This gets you around the problem that sometimes references are added by absolute path and sometimes they are added relatively. (there's something to do with "HintPath" which I can't really remember)
The nice thing then, is that you can still use the same solution files on your build server. Which to be honest is an absolute must as you lose the certainty that what is being built on the dev machine is the same as on the build server otherwise.
In our largest project (a system comprising of many applications) we have the following structure
/3rdPartyAssemblies /App1 /App2 /App3 /.....
All external assemblies are added to 3rdPartyAssemblies/Vendor/Version/...
We have a CoreBuild.sln file which acts as an MSBuild script for all of the assemblies that are shared to ensure building in dependancy order (ie, make sure App1.Interfaces is built before App2 as App2 has a reference to App1.Interfaces).
All inter-application references target the /bin folder (we don't use bin/debug and bin/release, just bin, this way the references remain the same and we just change the release configuration depending on the build target).
Cruise Control builds the core solution for any dependencies before building any other app, and because the 3rdPartAssemblies folder is present on the server we ensure developer machines and build server have the same development layout.
Usually, you would be creating Build projects/scripts in some form or another for your Production, and so putting together another Solution file doesn't come in the picture.
It would be easier to train everyone to use project references, and create a directory under the project file structure for external assembly references. This way everyone follows the same environment.
We have changed our project structure (making use of SVN Externals) where each project is now completely self-contained. That is, any references never go outwith the project directory (for example, if Project A references ASM X, then ASM X exists within a subfolder of ProjectA)
I suspect that this should go some way towards helping solve some of our problems, but I can still see some advantages of having more control over the build projects.
#David - believe it or not this is what we actually have just now, and yet it's still causing us problems!
We're making some changes though, which are forced upon us due to moving to TeamCity and multiple build agents - so we can't have references to directories outwith the current project, as I've mentioned in my previous answer.
Look at the Externals section of this link to see what I mean - http://www.dummzeuch.de/delphi/subversion/english.html
I would strongly recommend against this.
Reference paths aren't only stored in the .user file. A hint path is stored in the project file itself. You should never have to check a .user file into source control.
Let there be one set of (okay, possibly versioned) solution/project files which all developers use, and the Release configurations of which are what you're ultimately building in production. Having separate project files is going to cause confusion down the road, when some project setting is tweaked, not carried across, and slipped into production.
You might also check this out:
http://www.objectsharp.com/cs/blogs/barry/archive/2004/10/29/988.aspx
http://bytes.com/forum/thread268546.html