I have absolutely no idea, what does it means? I only press OK in assembly information in order to specify Assembly Version.
What paths is absent? And what operation VS2022 can not finished? It looks as Visual Studio programmers what is useful error messages are.
I just ran into this problem and for me it was a VB project, and when you modify the AssemblyInfo, it tries to write the AssemblyInfo.vb file to the .\My Projects\AssemblyInfo.vb. Normally when you create a fresh project, I think this folder is created automatically so VS assumes it's there and gives you this error if the folder is missing.
In my case the folder was not checked in to git, so when I checked out the project the folder was not there. I would assume the same is true for c# projects, except the folder expected would be .\Properties\AssemblyInfo.cs.
All I had to do was create the "My Projects" folder at the root of my project and the error went away. It appears you are using c#, so try creating a "Properties" folder at the root of your project and see if the error goes away.
I still don't understand what path Vs2022 can not found and what operation VS2022 can not complete, but manually add CS-file with needed attributes solve this issue.
Related
Unlike the other questions I've found on SO and elsewhere, this error is shown but no path is listed above the message, just the text:
Cannot find the resource compiler DLL.
Please make sure the path is correct.
Followed by another error:
The operation could not be completed. Unspecified error
I've tried logging and nothing different comes up, shows the same errors.
Tried the registry edit mentioned in this SO post and in this SO post. I have 3 keys in my registry directory
HKEY-LOCAL_MACHINE\SOFTWARE\Wow6443Node\Microsoft\Microsoft SDKs\Windows
v7.1A (the one I want that has the resource dll)
v8.0A
v8.1A
I deleted the 8.0* and still nothing. I've repaired VS to try to fix any issues but that didn't work. Tried adding the DLL directly to VS bin folder, putting the directory in the project Compile configuration, and added it to the PATH variable but nothing has worked. Any help would be greatly appreciated as I'm out of ideas.
The problem is definitely in the path to the resource dll, namely rcdll.dll, which the Visual Studio (devenv.exe) is reading from the registry. Try the key
HKEY-LOCAL_MACHINE\SOFTWARE\Wow6443Node\Microsoft\Microsoft SDKs\Windows\v8.1
Create it if it is absent, and add string parameter InstallationFolder with the path to the installed SDK:
C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\
Studio should accept this path. Then studio may not find dll in the path, this time showing the missing path in the message:
C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\bin\x86\rcdll.dll
Put (copy) dll to this path - this should be enough.
The main thing is to discover, which exactly registry key is studio reading. Here the utility procmon.exe from Sysinternals Suit will help - it tracks all accesses to the registry of specified process (devenv.exe). So, if specified paths above will be different in your configuration, use procmon and just track the registry key which is queried.
A C++/CLI project I maintain using VS2012 mysteriously stopped creating a .metagen file for one of its dll's for one build configuration. The metagen file is still created for other build configs. We use the metagen files so I need to build them for all configs.
I've tried searching project properties for differences between the broken build config and others, but saw nothing that seemed to have anything to do with metagen files. I've also searched online and found nothing useful about creating or suppressing creation of these files.
How do I turn metagen file creation back on for this dll in this build config?
I just solved that same problem when I understood that Visual studio was actually driving me to search at the wrong place. Indeed, my release build aborted and the first error message I saw repeated (eating all the error window) was unresolved symbols followed by indications of a missing metagen file...
All this was actually a consequence of a DLL link step failure much earlier in the build, that same DLL out of which the 'metagen' is possibly (automatically) extracted. So I advise you to go through your project dependencies in your solution and perform 'project only' builds step by step until you find the first failure. And best you look at the 'build ouput' panel to see the first error that arises instead of trusting the 'error' panel to present you with the root cause at the top.
In my case it was a silly mistake in a library directory path that entailed a subsequent DLL link failure, that entailed subsequent XAML unresolved members in that DLL namespace, that entailed plenty of missing metagen file errors...
I am trying to publish an application with VS2012 and when i try and make the package i get an error that access to the path is denied. I have checked and my user has full control and verified the path.
VS is trying to access .pubmxl file that is there.
I have also tried running VS2012 as administrator.
I had this same issue (VS2012: Access to path is denied when executing publish) and found a way to allow Visual Studio access to the file.
If you open the pubxml file in Visual Studio, make an edit, and save the file, Visual Studio is able to successfully publish using that file. Hope this works for you too.
Creating a new profile worked for me. I got this error when I tried to change the path of an existing profile, and Unfortunately I could not find the original pubxml file, otherwise I would have simply copied it to the new location and followed advice #1 (edit the file in location from VS2012). It's easy enough to create a new profile as there aren't many settings anyway.
I have experienced this issue and I noticed that the files were "Read-Only". Selecting the files and removing the "Read-Only" attribute allowed me to Publish successfully.
Sounds like TFS feature rocks again. Remove publish profile from local repo and get latest version afterwards, then you should be fine.
I had the same problem and fixed it by removing my Publish profile and creating a new one.
When I publish a ClickOnce application, one of the references that is included in one of my projects is missing.
If I go to my project's Properties -> Application Files, this missing reference is not even listed here.
My bin/Release folder has an .exe.manifest file, and I noticed it that it is also missing from here.
However, when I build the project, the DLL is in fact copied to my bin/Release folder.
How can I ensure it also deploys this required dependency?
I finally found a solution for this problem and I hope it will solve your problem to.
In my case, I'm editing an old application at work which have multiple projects, but the main project and it's back end project are the most important here.
The back end is added in the References section of the main project.
In the back end, a third party dll was imported, but this dll requires 2 other dlls.
So those 3 dlls were added in the References section of the back end project.
At that point, one of the 2 other dlls was not showing in the Application Files section for ClickOnce.
I've come up with a couple of ways of fixing it, but the most elegant one was to add this dll in the Reference section of the main project.
As stated in How to: Specify Which Files Are Published by ClickOnce, change the Copy Local property value on the reference to True.
References to assemblies (.dll files) are designated as follows when you add the reference: If Copy Local is False, it is marked by default as a prerequisite assembly (Prerequisite (Auto)) that must be present in the GAC before the application is installed. If Copy Local is True, the assembly is marked by default as an application assembly (Include (Auto)) and will be copied into the application folder at installation. A COM reference will appear in the Application Files dialog box (as an .ocx file) only if its Isolated property is set to True. By default, it will be included.
I know is this an old question, but for anybody having similar issues. I think this is a cleaner way around the problem.
I had a similar issue and everything I did to get ClickOnce to deploy with the offending .dll failed.
Eventually, I had to deploy manually.
See walk-through here.
That worked for perfectly for me. But, for the life of me, I still wonder why that process can't be added to VS (I'm using 2017 community).
My installshield project build gave such error:
"ISDEV : fatal error -1014: Cannot rename directory *\Release to
*\Release.Bak. Windows Explorer or a DOS prompt may be pointing to a subfolder of the release output folder (Disk1) or to the Interm
folder, locking it. Change the current directory. Close any open files
in the Disk1 folder. Close Msidb.exe if it is open."
The reason is because before I started the build I got a win explorer opened which was pointed to that release folder. And somehow ISDEV consider this as locking the folder, so it refused to proceed with the renaming.
Now, is there a way, like add some sort of script, to forcefully close all opened win explorer instance to release the socalled "lock" before the build script starts?
Thanks!
I know this is an old thread, but the problem is still around.
It seems the error is nothing to do with another process having the folder locked. I think InstallShield is fighting with itself by trying to rename a folder where IT still has some files open. That's why many of the traditional approaches such as closing explorer and even rebooting sometimes don't work.
I found a fairly simple solution is to delete the folder tree \Express from the Setup project folder before doing a build. InstallShield just recreates it and everything is OK because the rename was not needed.
This issue has been around as long as I remember working in my first IntallShield.
Don't try to beat the locking. Just make sure you don't keep explorer open on the release folder prior to the build. You can however navigate to its parent folder or better yet: define a post build distribution event.
The way I have found to remove that folder is to put something like this in the pre-build events:
RD fullPath\Express /S /Q
Because InstallShield project does not have the same properties as other projects do, I have inserted that in the Pre-build events at the properties of the main project of the solution.
Had the same problem, just closed InstallShield and re-opened it, worked like a charm.
Had the same problem, fixed it by Ending this task "InstallShield (R) 64-bit Setup Engine"