We have a number of standard devcontainer configurations that we wanted to publish in an internal repository. The Remote-Container extension has a configuration for this (Repository Configuration Paths), but I am unable to find any documentation on the format of the repository. Is there guidance on this somewhere?
Connect to multiple containers
Currently you can only connect to one container per Visual Studio Code window. However, you can spin up multiple VS Code windows to attach to them.
source: https://code.visualstudio.com/remote/advancedcontainers/connect-multiple-containers
Related
I had this problem on how to install my vb.net application i published a while ago. After i published the vb.net project, i copied the file and tried to install to another computer but, this error was shown.
Cannot download the application. The application is missing required files. Contact application vendor for assistance.
Can anybody help me please.
I need to run this application to other computers connected to my PC as the database server.
Just-In-Time Error when running the application to another computer
This error occurs when one or more of the files listed in the application manifest cannot be found on the server. I would suggest you open the application manifest in a text editor and verify that you have uploaded all the deployment's dependent files and also check manually if the ClickOnce Install Source is correct.
If you need more information for this case then read this
I am using a variation of Jeff Atwood’s Unhandled Exception handler it steps in when there is an Unhandled Exception in the application. It then logs the error, generates a screen shot and notifies the user.
When compiled in a solution the project generates an EXE that is called when needed. In updating the program I am using Visual Studio 13 to edit the existing settings items in the project properties. In the code I use commands such as this from ConfigurationManager.
string appProduct = unhandledExceptions.Properties.Settings.Default.AppProduct;
I was happy to see that it worked and reflected the changes I made in the IDE. However I couldn’t find the settings in the solutions generated confg file (MyApplication.exe.config). I assumed it was reaching back to the other project folder for the UnhandledExceptions.exe.config.
I created an installer and installed it to a virtual machine. My settings carried over, but again I could not see a config file.
It turns out the values are embedded in the executable UnhandledException.exe.
The project does not have any resources listed. Searching the web and StackOverflow looking a questions that want to do this, and there are a lot of them, it seems this was generally considered not possible and not desirable. Questions usually end in “You don’t want to do that, it’s called config for a reason”.
I may want to turn this off, so it is editable externally. The properties of app.config in both projects are identical.
What setting is making this possible after all? Is it a new capability with Visual Studio 2013?
There is no Visual Studio setting required. If you don’t want the user to have access to the configuration file, don’t include it in the distribution. One can always be added if the settings names are known.
In the description below application generically represents the name of the application being used.
I’ve found through observation some interesting things about the way ConfigurationManager works.
For User settings it will look in the following places in order of priority:
user.config for the application in the user’s AppData area
application.exe.config in the program folder
application.exe itself
Each setting is searched for individually. If your application requests a setting that is not found in either user.config or the application.exe.config it will get it from the executable.
For Application settings it looks in the following places in order of priority:
application.exe.config in the program folder
application.exe itself.
There is no equivalent to user.config for application settings.
Opening the application.exe in the Visual Studio IDE does not reveal a resource for the configuration information.
application.exe.config is handy because it can be modified externally and used as a default value for new installations. Once a setting is overridden in the user.config the value in application.exe.config is ignored.
The same is not true for the AppSettings section, the older configuration method from .Net 1.0. If I delete the configuration file it does not have them in the executable.
These observations were made with Visual Studio 2013 Update 4 and tested in Windows 7 Professional 64-bit. I suspect they are true in all versions.
'Hi all, I downloaded Xilium.CefGlue and built the source on Visual Studio (xilium-xilium.cefglue-b22787699e57), I also downloaded cef_binary_3.1453.1236_windows_xilium and copied the libcef.dll to the Xilium Winforms demo as the apps requires it to run but when I run it I get the following error:
An attempt was made to load a program with an incorrect format.
Exception from HRESULT: 0x8007000B
I've targeted x86, can I get some help?
Thanks
Ok, here's the steps I used to get the samples working in VS 2012:
Get the code from Xilium.CefGlue on github. (The one I used was c3d674a3a8)
Open the Xilium.CefGlue solution in VS2012
Remove or don't build the CefGlue.Demo.GtkSharp project (it didn't interest me & I didn't have the needed libraries)
In the Configuration Manager, select Active Solution Platform to be x86
Ensure that the target framework settings cooperate between projects. (e.g. CefGlue.Demo & CefGlue.Demo.WinForms by default are v2.0, but they depend on CefGlue which is v4.5) (For simplicity I set them all to v4.0 Client profile and it worked.)
Build solution — should succeed
Copy Xilium files from the unzipped cef_binary_3.1453.1236_windows_xilium to the output folder (bin\x86\Debug or bin\x86\Release). Minimum requirement seems to be:
libcef.dll and icudt.dll from .\Debug or .\Release
cef.pak and the locales\ folder from .out\Debug or .\Resources
Set CefGlue.Client as the StartUp Project
Run it
We have a silverlight(5) project, the source in TFS (2010) and Continuous Integration build has been setup and working fine. However, we are now at the stage where we are trying to release it to some users to get them using it and give feedback. I've set up the code so that it checks for updates and if there are any it downloads the latest xap file. However this requires the xap file to be signed. No problem when doing this from our dev machines, but when it comes to the automated build it fails, with the message
Xap packaging failed. Cannot locate the signing tool SignTool.exe.
I've tried numerous things to get the signtool to be recoginised and can't. However, we don't actually need this on the CI build, so I've then tried a second tack which is to make the postbuild event conditional on being run in VisualStudio. Followed various suggestions here on SO but can't gett them to work.
The post build event is
if "$(BuildingInsideVisualStudio)" == "true" (
"C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\signtool.exe" sign /f "$(SolutionDir)castle.pfx" "$(TargetDir)Castle.xap"
copy "$(TargetDir)Castle.xap" "$(SolutionDir)Castle.Web\ClientBin"
)
still no joy. Have tried multiple variations of this, but keep getting the same message from the automated build.
So can anyone help with either a) getting the signing tool to be recoginised on the build server or b) getting the automated build to skip the postbuild event?
Found the problem in the end...
I had been putting in place some features so the app would download and install the latest xap file. This requires it to be signed. As this wasn't working I followed some instructions on signing a xap file, not realising that one of the other developers here had put in place the code I described above in the post build event.
I had mistakenly thought that this was created as a result of me checking the 'Sign The Xap File' check box.
So first issue was that other developer had not shared his pfx file with us to add to our certificate stores.
Second, and main issue, was that we then had two attempts at signing going on. The one via the check box and the one via the post build event. I removed the check box and it worked fine.
The issue with the check box is that it expects the SignTool.exe to be in a particular location. On our development boxes with full VS it is where it is looking for it, but on the build server it wasn't. Think it may also have something to do with 64bit machines.
By using only the build event (once you have the correct certificates installed) you can specify explicitly the location that the signtool is going to be, and if necessary install the windows sdk to that location.
This is the top result in Google for this error so updating it with my steps to resolve.
The above didnt work for me but performing the steps below should fix it.
Install the Windows 8.1 SDK on the build server (Windows 2008 R2 for me)
Adding the Windows SDK BIN directory (that contains signtool.exe, on my server) to the Environment PATH variable - e.g. c:\program files (x86)\Windows Kits\8.1\bin - note: Do not add quotes around this
Restart all the Visual Studio Team Foundation services in services.msc after you add the file path to the PATH variable as it needs to reload these before building
I recently inherited a C# Winforms application that communicates with Quickbooks via their QBFC interface. The application contains a reference to the COM Server Interop.QBFC7.dll. The application works fine in our test environment and in several of our client's environments. Although, yesterday when I attempted to install it on a new customer's system I continued to get the following error:
Could Not Load File or Assembly 'Interop.QBFC, Version=8.0.0.87, Culture=neutral, PublicKeyToken=...' or one of its dependencies. The system cannot find the file specified.
I know that we have several customers running this application on various versions of Quickbooks (i.e. Quickbooks Pro, Premier and Enterprise between 2008 and Enterprise 11.0). To my knowledge, this is the first customer that we have attempted to deploy this application that has Enterprise 12.0.
I have attempted the following to resolve the issue with no success:
1) Install the QBFC7_Installer from the Intuit Developer Network Site
2) Install the Quickbooks SDK 10 Installer from the Intuit Developer Network Site
3) Verified that the Interop.QBFC7.dll file is present on the file system.
4) Attempted to manually register the COM object Interop.QBFC7.dll via the command prompt: regsvr32 Interop.QBFC7.dll (This fails as well and windows returns an error stating that it cannot find the object).
Does anyone have any suggestions or feedback about additional things that I can try to resolve this issue? I get the same error on 3 different machines at their site running different operating systems (i.e. Windows Server 2008, Windows 7, and Windows Vista)? I have also tried compiling in both x86 and 64-bit configurations to no avail.
Thanks in advance for any help.
First of all, you should be targeting an x86 build only. The QuickBooks SDK won't work if you target Any CPU or x64. Your main problem, though, is that you are looking for the wrong version of QBFC. Notice the version stamp on your error message:
Could Not Load File or Assembly 'Interop.QBFC, Version=8.0.0.87,
Culture=neutral, PublicKeyToken=...' or one of its dependencies. The
system cannot find the file specified
This is QBFC8, not QBFC7. So you should be able to fix the problem with the QBFC8 installer.
The version of QuickBooks should not make a difference, since QBFC 8 (or 7, for that matter) will work with the 2008 and Enterprise 11 or 12.
You should look into using a setup project to install your application in order to avoid this problem in the future. A setup project should detect the QBFC dependency automatically. Once you see this happening, go to SearchPath property of your setup project and add the MergeModule directory from the SDK that is installed on your machine. Once you do this, you should see that the QBFC and Xerces merge modules are added to your project automatically as dependencies. Of course, you'll also need to update your code to a more recent version of QBFC, but that's probably a good idea in any case.