In Visual Studio 2015 it is possible to select which version of the C# language is being coded in, as shown here.
I'm looking for the same option for VB.NET - how can I restrict syntax, etc. to old VB.NET versions?
I want to do this so that I stop accidentally using VB 14 features in a project I'm sharing with someone using Visual Studio 2012. I'd rather not spam up my machine with a Visual Studio 2012 install or have to create a new VM for a fairly occasional requirement.
NOTE: I don't want to change the target .NET Framework version.
The VB.NET compiler has the /langversion option for this. Also supported by MSBuild. But not by the IDE, that makes it awkward to change it.
Still possible, you have to edit the .vbproj file. Use a text editor, Notepad will do. And copy/paste this snippet, insert it in the 4th line so it is effective for all configurations and platforms:
<PropertyGroup>
<LangVersion>12</LangVersion>
</PropertyGroup>
And double-check that it is effective:
Module Module1
Sub Main()
Dim test As String
Console.WriteLine(NameOf(test))
End Sub
End Module
Output:
error BC36716: Visual Basic 12.0 does not support 'nameof' expressions.
Well, that works, also flagged by IntelliSense with red squiggles. You probably want to create your own project templates so you don't have to do this over and over again. Use File > Export Template.
If you're using ReSharper it turns out this is an option:
Left Click on the project in Solution Explorer
Select the Properties Window (not the Project Properties - you want the properties snap in)
Under ReSharper options there is a "VB Language Level" option, which gives options all the way back to VB.NET 8.
I haven't tested how well this works.
I don't think this is possible when using VB.
See this related connect bug: Connect: VB 14 compiler removes line continuations even when web.config specifies VB 8 as compiler
Related
We used FXCOP code analysis ("legacy") a lot in our solution. We are turning on many Microsoft rules, and also have written a large set of our own FXCOP-style analyzers for aspects of code that we wanted to have checked. And it all worked quite well in the "old" style Visual Studio C# projects, aimed at various .NET Framework versions (currently 4.7.2).
When, however, the same project is ported to the new "SDK-style" format, and made to target .NET Framework 4.7.2 by having net472, and we enable the code analysis by adding true, we run into a problem. Our custom FXCOP rules appear to still work well and output their warnings, but in the Error List window, there are no file names under the "File" column, and there is always line 1 under the "Line" column. Consequently, we can see the warning messages, but it is impossible to double-click on the warning and figure out the location in the source code the warning related to - which makes the whole code analysis useless. When I switch to the Output/Build window, I can also see the warnings there line by line, but the file name/line number information is missing here as well.
I am aware of the followings facts:
That Microsoft has ported many or all their FXCOP rules to Roslyn (".NET Analyzers") and they can/should now be used. However I need to use our own rules, not just the Microsoft rules. Rewriting our rules to Roslyn may be the right solution in the long run, but it would be a huge undertaking in short- or mid-term.
That FXCOP (legacy) analysis is not supported in .NET Core and .NET Standard projects in VS (as per https://learn.microsoft.com/en-us/visualstudio/code-quality/static-code-analysis-for-managed-code-overview?view=vs-2022 ). My project is not, however, for .NET Core or .NET Standard, as I described above. It is for .NET Framework 4.7.2 - the problem seems to be in the fact that it is the SDK-style. And the reason I need it in this format is because it is the format that I will then use to port to .NET Core/.NET 6+.
I have a found a partial solution to the problem. The reason FxCopCmd (which is used by this) does not emit file names and line numbers is because by default, in SDK-style projects, the PDB file format is set to portable. FxCopCmd does not understand the portable PDB. The solution is in Visual Studio project properties, set the "Debug symbols" to "PDB file, current platform". The corresponding setting in the .csproj file is
<DebugType>full</DebugType>
After making this change, the file names and lines numbers appear in the text output, and in their columns in Error List, and it is possible to click on warnings in the output or Error List, and you will be taken to the right place in the source.
What does not work yet: The "Suppress..." contextual menu commands in the Error List still do not appear.
So I'm having to run someone else's excel app on my PC, and I'm getting "Can't find Project or Library" on standard functions such as date, format, hex, mid, etc.
Some research indicates that if I prefix these functions with "VBA." as in "VBA.Date" then it'll work fine.
Webpages suggest it has to do with my project references on my system, whereas they must be ok on the developer's system. I'm going to be dealing with this for some time from others, and will be distributing these applications to many others, so I need to understand what's wrong with my excel setup that I need to fix, or what needs to be changed in the xls file so that it'll run on a variety of systems. I'd like to avoid making everyone use "VBA." as an explicit reference, but if there's no ideal solution I suppose that's what we'll have to do.
How do I make "VBA." implicit in my project properties/references/etc?
-Adam
I have seen errors on standard functions if there was a reference to a totally different library missing.
In the VBA editor launch the Compile command from the menu and then check the References dialog to see if there is anything missing and if so try to add these libraries.
In general it seems to be good practice to compile the complete VBA code and then saving the document before distribution.
I had the same problem. This worked for me:
In VB go to Tools ยป References
Uncheck the library "Crystal Analysis Common Controls 1.0". Or any library.
Just leave these 5 references:
Visual Basic For Applications (This is the library that defines the VBA language.)
Microsoft Excel Object Library (This defines all of the elements of Excel.)
OLE Automation (This specifies the types for linking and embedding documents and for automation of other applications and the "plumbing" of the COM system that Excel uses to communicate with the outside world.)
Microsoft Office (This defines things that are common to all Office programs such as Command Bars and Command Bar controls.)
Microsoft Forms 2.0 This is required if you are using a User Form. This library defines things like the user form and the controls that you can place on a form.
Then Save.
I have experienced this exact problem and found, on the users machine, one of the libraries I depended on was marked as "MISSING" in the references dialog. In that case it was some office font library that was available in my version of Office 2007, but not on the client desktop.
The error you get is a complete red herring (as pointed out by divo).
Fortunately I wasn't using anything from the library, so I was able to remove it from the XLA references entirely. I guess, an extension of divo' suggested best practice would be for testing to check the XLA on all the target Office versions (not a bad idea in any case).
In my case, it was that the function was AMBIGUOUS as it was defined in the VBA library (present in my references), and also in the Microsoft Office Object Library (also present). I removed the Microsoft Office Object Library, and voila! No need to use the VBA. prefix.
In my case, I could not even open "References" in the Visual Basic window. I even tried reinstalling Office 365 and that didn't work. Finally, I tried disabling macros in the "Trust Center" settings. When I restarted Excel, I got the warning message that macros were disabled, and when I clicked on "enable" I no longer got the error message.
Later I re-enabled all macros in the "Trust Center" settings, and the error message didn't show up!
Hey, if nothing else works for you, try the above; it worked for me! :)
Update:
The issue returned, and this is how I "fixed" it the second time:
I opened my workbook in Excel online (Office 365, in the browser, which doesn't support macros anyway), saved it with a new file name (still using .xlsm file extension), and reopened in the desktop software. It worked.
Even when all references are fine the prefix problem causes compile errors.
What about creating a find and replace sub for all 'built-in VBA functions' in all modules,
like this:
replace text in code module
e.g. "= Date" will be replaced with "= VBA.Date".
e.g. " Date(" will be replaced with " VBA.Date(" .
(excluding "dim t As Date" or "mydate")
All vba functions for find and replace are written here :
vba functions list
For those of you who haven't found any of the other answers work for you.
Try this:
Close out of the file, email it to yourself or if you're at work, paste it from the network drive to your desktop, anything to get it to open in "protected mode".
Now open the file
DON'T CLICK ANY ENABLE EDITING OR THE YELLOW RIBBON
Go to the VBA Editor
Go to Debug - - Compile VBA Project, if "Compile VBA Project" is greyed out, then you may need to click the yellow ribbon one time to enable the content, but DO NOT enable macros.
After you click Compile, save, close out of the file. Reopen it, enable everything and it should be OK. This has worked for me 100% of the time.
In my case I was checking work done on my office computer (with Visio installed) at home (no Visio). Even though VBA appeared to be getting hung up on simple default functions, the problem was that I had references to the Visio libraries still active.
I found references to an AVAYA/CMS programme file? Totally random, this was in MS Access, nothing to do with AVAYA. I do have AVAYA on my PC, and others don't, so this explains why it worked on my machine and not others - but not how Access got linked to AVAYA. Anyway - I just unchecked the reference and that seems to have fixed the problem
I've had this error on and off for around two years in a several XLSM files (which is most annoying as when it occurs there is nothing wrong with the file! - I suspect orphaned Excel processes are part of the problem)
The most efficient solution I had found has been to use Python with oletools
https://github.com/decalage2/oletools/wiki/Install and extract the VBA code all the modules and save in a text file.
Then I simply rename the file to zip file (backup just in case!), open up this zip file and delete the xl/vbaProject.bin file. Rename back to XLSX and should be good to go.
Copy in the saved VBA code (which will need cleaning of line breaks, comments and other stuff. Will also need to add in missing libraries.
This has saved me when other methods haven't.
YMMV.
For my project, I need to generate CAD drawing (almost a blueprint of a tank) through my VB.NET application. The app takes in some user input & based on this, it generates the geometry of the tank.
I am using Microsoft Visual Studio Professional 2012 & coding in the VB.NET language.
I have browsed through a lot of AutoCAD documentation but could not find exactly how & where are the modules hidden, for me to add them into my code.
I stumbled accross one particular document
which is where I found how to add the relevant files as reference to my VB solution. However, after adding some particular files I could then do Imports AutoCAD, but all the docs show that I must use Autodesk.AutoCAD. On inspection of the available modules/methods of the Imports AutoCAD I can see that it isn't complete as needed for the application development.
Can somebody please guide me as to how could I find or go about adding correct reference files to my VS solution to get full functionality from the AutoCAD modules? Thanks!
I posted this quite some time ago. It contains the information that you need
How to close a file in Autocad using C# keeping acad.exe running?
You can also download any of the AutoCAD .NET API's from here:
http://usa.autodesk.com/adsk/servlet/index?id=1911627&siteID=123112
Just in case someone else need the help.
Download the appropriate AutoCAD .NET API using the aforementioned link.
Put them in a location of your choosing.
general:
on the appropriate project in your visual studio's solution, right click -> Add Reference.
select Browse on left, click the browse button and go to the path where you saved the ObjectARX download.
Inprocess:
Navigate to the inc directory and
select the AcDbMgd.dll and AcMgd.dll then click add.
For these make sure to set the copy local property to false.
Interop:
Navigate to the appropriate directory: inc-win32 or inc-x64 depending on your processor.
select the Autodesk.AutoCAD.Interop.Common.dll and Autodesk.AutoCAD.Interop.dll then click add.
and unless you have an interest in the AutoCAD interface don't worry about the AcCui.dll
Hope this helps some one out :)
So, looking up more & more documentation led me to stumble across this
I found the dlls by simple file search for respective dlls metioned below in my local AutoCAD 2014 installation folder (C:\Program Files\Autodesk\AutoCAD 2014)
As per the documentation, following dlls are important ones -
AcCui.dll
acdbmgd.dll
acmgd.dll
Autodesk.AutoCAD.Interop.dll
Autodesk.AutoCAD.Interop.Common.dll
The credit for the last 2 dlls goes to Trae Moore.
How to add references to the dlls was mentioned in the documentation link.
I have a blocking error in vb 2008( windows forms application ).
In my project I used excel 2010. I have added the statement 'Microsoft.Office.Interop.Excel' in my program. I got a error that it is not a namespace member.
I learned that I need go add reference of a library component and so I downloaded and installed primary interop assembly service for excel 2010. Even now if I add my reference I get no change in components.
Still the same error.
help please.its urgent
Have you Office installed?
If not, you cannot use Interop.
If you have installed Office you should add a reference:
Go to my project -> references -> add -> com -> microsoft.excel.12(14).library. Then it should work. The 14 denotes that, depending on your version, the exact number will vary.
If you have no excel installed, you could try EPPLUS: http://epplus.codeplex.com/
It is a great library to read / write xlsx files, much more quickly and more comprehensible than interop.
I have VB.NET code in Visual Studio 2008 using an obsolete method and would like to suppress the warning. Unfortunately, following the recommendation is not a good solution, because it requires using a different class, which works differently, in important ways.
I'm trying to suppress the warning using System.Diagnostics.CodeAnalysis.SuppressMessage, but I don't know what to write as the parameters for the attribute and can't find any relevant reference.
I should also say that, right-clicking on the error in the error list I don't have any 'Suppress Message' option.
If you're using Visual Studio you can do the following.
Right click on the project and select "unload"
Right click on the project and select "Edit SomeProjectName.vbproj"
You should see two XML element tags with the name "NoWarn". Add the number 40000 to the list of numbers already present (make sure to do this for every NoWarn tag in the file)
Save the file
Right click on the project and select reload (you'll have to close the .vbproj file)
This will get rid of the warning. The number 40000 is the VB.Net error number for the obselete warning. You can suppress any warning in this fashion.
Note: If the NoWarn tag is not present, add it to the main PropertyGroup element with the following values
<NoWarn>40000</NoWarn>
In VS.NET you can right click on and suppress code analysis warnings. This will add the attribute for you.
However, the "don't use obsolete APIs" warning is not coming from code analysis, and so the SurpressMessage attibute won't work. This is a compiler warning.
For VS.NET you'd need to switch off this warning with...
/nowarn:0618
... at the command line (or just adding "0618" into the Suppress Warnings field on the csproj properties). You should do the same with whatever the VB warning number is.
I was able to resolve this with JaredPar's answer in my VB Project, thanks!
I did had same warning for my C# test project that I got removed by adding 618 in suppress warning section of Build Tab in Project Properties.
Please remember the Error Codes for VB and C# are different.
If one want to correct the these warnings then one need to install and use ODP.NET for Microsoft OracleClient Developers
Microsoft is deprecating System.Data.OracleClient, also known as Microsoft OracleClient. Microsoft OracleClient provider developers can use this opportunity to reevaluate which data provider to use for current and upcoming projects. Oracle recommends to start building new Oracle .NET applications with Oracle Data Provider for .NET (ODP.NET) and migrate existing applications to ODP.NET.
http://www.oracle.com/technetwork/topics/dotnet/index-085703.html