Problem using the Find References (Inno Setup) feature in Visual & Installer - visual-and-installer

Let us say that I want to find all instances of where AddFileForDownload in used in my script to Visual & Installer in Visual Studio.
When I do it to usual way:
And it produces results as I expect:
But when I try to use the bespoke feature in Visual & Installer:
I end up with this:
If I drag the pane out it then looks like this:
I am using:
Visual Studio 2019 (16.6.2)
Visual & Installer (1.0.4.8)

This is an issue in VS 2019 which is caused by blocking any extension from synchronously autoloading since 16.1, see: https://devblogs.microsoft.com/visualstudio/updates-to-synchronous-autoload-of-extensions-in-visual-studio-2019/
In V&I this applies to Suggestions (Light Bulb actions - Add File(s) / Add Folder into script) and the References window. Both must be reworked/fixed for VS 2019.
The Suggestions are already done and we are currently working on the References window.
Both will be ready in next V&I release.
Update 27-11-2020: The transparent (blank) controls in References windows are caused by changes in .net DPI awareness: https://blog.jetbrains.com/dotnet/2019/06/11/blank-tool-windows-resharper-visual-studio-2019-net-framework-4-8-per-monitor-dpi-awareness/
Temporary solution is to uncheck Optimize rendering for screens with different pixel densities via Tools | Options, then Environment | General.
Update 2020-11-30: Today we have released an updated version of this tool where we have fixed this issue (it is necessary to reinstall the extension in Visual Studio 2019).
See the details and get latest version from official website: http://visual-installer.com/changelog.html#10410

Related

wxWidgets - wxUSE_UNICODE_MSLU not defined when building minimal sample using binary in Visual Studio

I'm trying to build the minimal wxWidgets sample on Windows, using Visual Studio 2019 Commmunity Edition, following the instructions from this page for using wxwidget binaries
I opened the "minimal_vc9.vcxproj" file in Visual Studio. Visual Studio upgrades the project file.
I then added the wxwidgets.props property file to the property manager, and then tried to build ( Build | Build Solution )
It fails with the following error:
1>C:\Users\Administrator\Desktop\wxwidgets\include\wx\msw\chkconf.h(91,1):
fatal error C1189: #error: "wxUSE_UNICODE_MSLU must be defined."
I am trying to help a friend who knows C++ and uses Windows to set this up, but am not sure how to do so. Note both he and I are new to using Visual Studio as well, and I can't find any references on how to fix this by Googling.
Note I am using the project file that came with minimal (no solution file was there), and can see that in it's configuration that it says "Use Unicode Character Set" at `Project | Properties | Character Set"
EDIT: I'm attaching a picture of the IDE/files we downloaded, which I believe are the 3.1.5 version, ie release version as of Dec 4, 2021?
It looks like you're using wxWidgets 3.0, as support for MSLU was removed since v3.1.0 ~8 years ago. Please download 3.1.5 binaries and open minimal.vcxproj project file to build the sample, there is really no reason to use a 10 year old version if you're starting developing with wx.
Also, completely unrelated, but it's considered to be a bad idea to use administrator account for development. wxWidgets certainly doesn't require any special rights.
I
It is very easy to build the library yourself.
Download the source code archive and unpack it in, e.g. c:\wxWidgets
Start msvc, do ^File->Open", navigate to c:\wxWidgets\build\msw and open the file wx_vc15.sln
Select "Build->Batch Build...", click "Select All", then "Build".
When the build is finished successfully, open c:\wxWidgets\samples\minimal\minimal_vc9.sln, let msvc convert it and choose " Build->Build Solution".
Then when everything is ready, create a project as "desktop application", apply the properties file and start coding.
Thank you.

Xamarin, effect of platform build tools (android)

I'm coding on xamarin to create an Android-form test application in vs2017.
The coding isn't the problem its rather the environment.
So far the biggest problem has been getting it all to work in vs2017. I managed to get it mostly working, with minor (yellow) errors left.
Now the device xaml preview works !!
The Visual studio / (or should I say intel Haxm) emulator works !!
And I can use the live player as well !!.
My program can be seen on all of above (also on my mobile).
So now that it finally all works (fixing the environment took quite a while).
I got carefully to update my environment and xamrin, and I wonder I have installed Android build tools 26 and 25. (As I want my code to run on my older 4.4.2 version of android phone. Would it be fine to install android build tools 27.0.3 as well??.
Or will adding another sdk-build-tools cause havoc (dependency troubles).
I'm not sure if those build tools are independent from the rest of xamarin / .net core
build tools used, should be latest only,sdk build tools are independent, if u r talking about sdk tools then u can add as many as u want like if u want your emulator to be run on that sdk version then u need to download or else downloading multiple sdks will affects only to size nothing else

Conflicts between copied VS solutions

I'm experiencing some strange behaviour with my ASP.NET MVC 5 application, running on Visual Studio Ultimate 2013, in Windows 8 Professional, and using MongoDB 2.6 as the database.
Originally, there was one solution; let's call this Alpha. Then, I copied the solution (literally copied and pasted in Windows Explorer), to create a new solution; let's call this one Bravo. I changed the solution and project name and all associated filenames, then edited the content of Bravo significantly such that it appeared very different to Alpha when the application was run in a browser.
The strange behaviour is as follows. If I am working with Bravo in Visual Studio, and I run it in a browser, then everything appears as would be expected with Bravo. However, if I then load Alpha in Visual Studio, and then I run Bravo, then the website that is displayed is actually that represented by the code in Alpha, not Bravo. If I then close Visual Studio instance running Bravo, restart it, and then run the Bravo application, the website displayed is back to the expected version for Bravo.
So, it seems that there is still something remaining in Bravo that is referencing Alpha. If I load up Alpha, then something is being loaded into memory which overrides the data which Bravo provides during the application launch. Only when I restart Visual Studio and refresh this memory with Bravo, does it run with the updated version of Bravo, rather than the original version of Alpha.
Similarly, if I have Alpha loaded in Visual Studio, and then load the Bravo solution in another instance of Visual Studio, then run Alpha - it displays what I would expect to appear from Bravo.
Any ideas on what is causing this behaviour, or how I might investigate this further?
Thanks :)
Sergey is correct.
I have this happen all the time, when going back and forth between web solutions that I host in IIS, I always have to change the paths back and forth. This started with VS 2012 and continued in VS 2013.
I can't find much information on why it is happening or how to correct it. There are only work-arounds as far as I can tell.
Workaround and info on the bug request
another potential post on same subject.
I personally, just manually change it back and forth.

Created MSI but get installation package is not supported by this processor type error

I'm new to MSI's. I've created a Window's Service that is the output project for my MSI. My local machine is a 64-bit Win 7 machine. The server I am trying to install on is a Win 2008 32-bit server running on a VM. I'm using .NET 4 VS2010.
Currently, my service's exe is building as a release target = Any CPU in the Config Manager. The MSI, does not give me any option to change the platform.
I can install no problem on my local 64-bit Win7 machine. However, whenever I try to install on the 32-bit Win 2008 I get the following error:
"This installation package is not supported by this processor type error. Contact your product vendor."
I tried changing the service's target to x86 rebuilding the exe and the setup, but I get the same result. The service references a number of class libraries. I changed those from Any Cpu to x86 as well just to see if that made any difference.
I also, made sure that my Setup project and Service Prerequisites are set to .NET Framework 4 (x86 and x64). I also experimented with changing the Prerequisites Windows Installer from 3.1 to 4.5.
Nothing seems to work. Any ideas? Thanks.
In my case, having entries specified under the HKLM/SOFTWARE (64-Bit) registry node was enough to cause installation failure on a 32bit Win7 host.
The symptoms were the same for VS 2010/2013 using the free, integrated InstallShield product. I was able to keep the Any CPU settings on the project being installed. There were no other special settings required for the MSI setup project.
OK, I figured out where the TargetPlatform is. It is different than on other VS Projects.
To access the TargetPlatform, select the MSI project and press the F4 key. Viola! Within the "Properties" grid, you will find the TargetPlatform field with options: x86, x64, Itanium. NOTE: this is a completely different set of properties that you get when you Right-Click on a project and select the "Properties (Alt-Enter)" item from the context menu. "Alt-Enter" Properties vs "F4" Properties.
Unfortunately, this is different than the other VS Project properties. Typically, Project Properties are set in the Main Window, not here in the "F4" properties grid. Hence, I kept getting confused when other threads discussed the properties of the project since this is different.
such as this one
ConfigurationManager in VS does not affect the MSI. I'm keeping all my dependent assemblies on "Any CPU". Also, don't forget target the correct framework in the "Launch Conditions" Window (right-click project -> View -> TargetConditions).
Hope this helps.
I am kind of late to answer this question! F4 does not work on Visual Studio 2017. Just highlight the Setup project, then right-click on Properties-tab on the RIGHT side-bar. Then change the "TargetPlatform" to your desired option. Please, note: This is different from right-clicking on the Setup project.

Tfs project have red x on it and can't expand to work items, source etc. on one machine

I have a user that is trying to access a team project that he has been working with (in).
He has 2 computers, on 1 he can access it, on the other he can't (project has red x). And actually he can access any projects on that machine, all have the same red X.
He was been able to accesses the project on both machines last week. And I have no idea what could have changed.
Searching the web found a # of post regarding folder within a project with a red X but not much on a project itself. But we tried these 2 links ...did not help
visualstudiomagazine
social.msdn.microsoft
Also tried re-installing Team Explorer & installed SP 1 (it was not on the machine).
Any ideas where to start looking?
Thanks
The 'Red X' problem can be from many different causes.
However, seeing as the user is experiencing the problem on one machine, and not on the other means that it's unlikely to be a server-side issue.
On the computer that is having the problem:
Close all instances of Visual Studio
Close any other applications that could be using the TFS Object Model
Open and delete the contents of the following folder: %localappdata%\microsoft\Team Foundation. On Win7, this will typically expand to something like C:\Users\<username>\AppData\Local\Microsoft\Team Foundation
Start Visual Studio again and connect to TFS
TFS clients have a local cache of metadata. There are situations where this metadata can get corrupted. Therefore, deleting it will force a fresh download of the metadata and resolve the Red X issue.
Enabling tracing on the client and/or TFS server should allow you to track down the error.
This happened to me after installing .NET 1.1, Visual Studio 2003, Active Reports 2.0 and Dundas Charts on 64-bit Win 7. None of the other fixes worked for me, but I resolved my issues (which also included weird IE behavior) after running the ie8-rereg.32-on-64.cmd script found here: http://iefaq.info/index.php?action=artikel&cat=42&id=133&artlang=en.

Resources