We Keep Coding

Imported website into web application in visual studio gives 'Type typename already defines a member'

After importing this existing (and functional) site into Visual studio (tried 2017 and 2019 both) running .Net 4.0 I am getting a plethora of not found errors.
Codebehind pages are not able to see elements on the existing page
Classes are declared to be duplicated or ambiguous
Function names (both standard like Page_Load and custom) are reported as already defined.
I am sure that all these items are related. Here are the steps I followed:
Created new Web Application from Visual Studio 2017 template
Copied solution and csproject files into existing website folder
Added files into the project
Re-added references to site
Set custom class .CS files to Compile
Removed "unnecessary" using statements (which were already declared in web.config)
Create a new ProfileCommon stub referencing ProfileBase
Beyond all this I have tried renaming a number of these functions and classes (using the rename) to create a new reference point.
Not sure what else I can do on this beyond major changes or a complete rewrite (100+ pages of code so far) by creating the new class files then copy/paste.
What other options are open to me?

Ok, this is is a migration project. Only you can "determine" if you want to convert from a web site to a web site application, and the time and efforts for such a migration project.
Now, having stated the above? No question, that I prefer hands down a web site applications. Simple things like have VS compile and build the application, ability to add assemblies (and not have the mess of .dll's HAVING to be in the bin folder to resolve references - yuk!).
And then simple things like the ability to multiple projects in one project are things I come to enjoy, and expect over the years when developing software.
About the "only" thing going for a web site? Your deployment is oh so easy, since you can open a web page, or code behind, hit save, and you are done!
but, this means both source code (code behind) has to be deployed to the web site. As noted, I prefer a build and compile process in VS. This does mean that to make a "minor" change, then you have to do a full re-deploy of the whole site.
However, these benefits I like and enjoy? it not all a given that converting an existing web site to a web site application is worth the efforts. Only you can make this decision. On the other hand, you would not be doing this work unless you KNOW what you doing, and thus can determine if these efforts are worth the time.
Such a conversion and refactoring process is somewhat beyond a simple post on SO.
However some steps and tips are outlined here:
https://devblogs.microsoft.com/dotnet/converting-a-web-site-project-to-a-web-application-project/
I would consider starting over, and try the steps in above.
There is a "convert" option outlined in above, and this can save enormous amounts of time. It has been some time since I have attempted such a conversion, and I not tested the "convert" option in vs2022, and hopefully it still exists.
However, another possible option? Keep the site as web site.

How do I import MySql Connector into Unity Project?

I've tried placing the basic dll's into unity's assets folder - Result: "blah blah will cause Unity to Crash Error."
I've tried Manually adding references - Result: Unity refreshes its references anytime the editor refreshes, so worthless.
I've tried Installing using NuGet - Result: Closest to success as it handles all the dependencies and whatnot but I get: Assets/Scripts/Developing/TalkToDB.cs(3,7): error CS0246: The type or namespace name `MySql' could not be found. Are you missing an assembly reference?
Is it some kind of a combination of "Use NuGet then copy the dll into the Assets?" or something redundant like that? cause that's about the best guess I've got.
Also, I've tried a couple older versions of the NuGet package to no avail.
As well, MySql.Data is listed under the References of "Assembly-CSharp"
And my Unity is set to 4.X framework Using Unity's latest 2018.2.5f1 (64bit)
(I really hope that I don't have to ditch 4.x for this to work... I'll miss initializing values to properties..)

Fortunately I came across this:
How to get MySql Connector/Net Working with Unity 2017
And Regarding Security concerns. My Key is none of my sessions should ever be persistent from .NET - There will be advanced PHP scripts for altering of data and anything regarding elevated permissions.
Reference: Why you shouldn’t connect your mobile application to a database
Beyond this,
Exceptions to the rule.
"Some database vendors may have provided drivers to connect to remote databases, but as yet I’m not aware of any.
Other exceptions include ODBC connectivity. For example, I’ve heard of developers being able to (or at least trying to) connect to MySQL databases using JDBC when developing applications in Java. This is not actually quite the same as connecting directly using a binary driver, however, it comes close..."
- 2
This is exactly what I will be doing, using the MySql Connector to talk to MySql drivers (which I'm too tired at the moment to recall the name of(maybe it's based on ODBC? I can't remember. Thus Google. Lol))
So all in all, using the link provided at the top, Unity 2018 can be compatible with the latest (as of this post) MySql Connector(s).
Any Assets folder must contain: System.Data.dll & MySql.Data.dll (that's it)
No NuGet required.
However the error message: "Loading script assembly 'Assets/Plugins/MySql/System.Data.dll' failed!"
And as of yet, it is apparently not able to reference connectionString from an app.config like your normal C# outside of Unity would be able to.
This being said, I'm working on finding either Unity's implementation of the app.config, or an equivalent alternative.
UPDATE:
Aside from a couple annoying dll loading errors in Unity that don't influence anything - other than annoying me and wasting a couple bytes of RAM for a second (lol, y'kno.);
All works well and I remember the reason I am not concerned about connecting my application directly to my Database is because the ONLY permissions the users will have is the Execute permission so all procedures will be stored on the server (via Stored Procedures) and thus protecting the database against any potential attacks even if cough coughwhencough ahem, a user decides to "de-compile" (is that even a word...? heh) my application.
Final Update:
As I posted here;
It took me a week to finally figure it out...
You need to use:
I18N.dll
I18N.West.dll
I18N.*.dll (Optional, they are region specific)
System.Data.dll
from C:\Program Files\Unity\Editor\Data\Mono\lib\mono\2.0
NOT the BleedingEdge path. Then it will work without errors [And in Builds]...
confirmed in the latest Unity 2018.2.14f1
Place into the Assets folder - Also the project needs to be set to .Net 4.0

Silverlight web service update fails to import wsdl

We've been battling with a strange issue for a couple of days now. Have searched the net for answers but none seem to solve the error.
Our scenario is: our organization has a Silverlight 5 application, which was developed in VS 2010, and everything was working fine. It is actually running in our production servers.Recently we migrated our development machines to VS 2015, and the machines themselves (new ones for the dept). The OS is Windows 7, same as before.
At first we were welcomed with that nasty MatchTimeoutInMilliseconds error, due to the MS Framework. Eventually MS released the 4.6.2 Preview version which covered this issue.
Ok. So back to implementing the changes requested, we created a new method in our webservice, and it complied just fine. We do have the [OperationContract] and [DataContract] tags in place. There is a question posted and answered with the justification that these tags were missing.However, when we go to the SL app and update the WS reference, we get this "Custom tool error: Failed to generate code for the service reference ..."
Custom Tool Warning messages include
"Cannot import wsdl:binding..."
"Cannot import wsdl:port..."
"Cannot import wsdl:portType..."
"No endpoints compatible with Silverlight 5 were found. The generated client class will not be usable unless endpoint information is provided via the constructor."
We're puzzled, because then we thought we might have done something wrong, so we rolled back the changes, and updated the service reference with no changes, and we get the same error. The Referece.cs file is generated with no code, and all references to the webservice are no longer recognized by the compiler.
We've also read some posts that offer as a solution unchecking "Reuse types in referenced assemblies". Doing that does clear these errors, only to generate others, since our app was built on this premise.
We've also tried deleting the service reference and adding it back again, but to no avail.
Eventually we reverted the SL app to the point it was compiling, which was before updating the webservice reference, republished the WS with the new method, and manually added the new method to the Reference.cs file, tested it and it works.
This, however, should not be -the- solution. It's a hassle and prone to errors.
We'd appreciate any help in solving this matter, or an insight as to why this is happening.
thanks

The whole problem is that, for some reason I still haven't found, VS fails to generate the code for Reference.cs.
As a workaround, we've managed to generate the Reference.cs file by using the SlSvcUtil.exe tool, located (on my machine) at "c:\Program Files (x86)\Microsoft SDKs\Silverlight\v5.0\Tools".
In order to get the same code as the one generated before the migration, I've used the following command and options:
SlSvcUtil.exe my_ws_address /namespace:"*,my_class_namespace" /ct:System.Collections.ObjectModel.ObservableCollection`1 /r:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\Silverlight\v5.0\System.Windows.dll" /edb /ser:Auto
I didn't use the /out switch, but rather ran the command on my desired output directory. But you might want to look into that switch before running the command.

Unable to load "lpsolve55.dll" in VS2015 on 64-bits OS

For a project I am working on, I need to solve a mathematical model. I chose to do this using Microsoft.Solver.Foundation and the SolverFoundation.Plugin.LpSolve plugin. Both associated .dll files for these extension seem to work fine, as VS2015 recognizes and references them without a problem and compiles and runs my program without errors.
This is however up untill I try to actually solve my optimization, which needs "lpsolve55.dll" to work. I have downloaded this dll and put it in my project's bin/Debug folder, but for some kind of reason VS2015 just doesn't recognize it. I.e.
I can't reference it by simply browsing to it from my "Add Reference" tab.
It's impossible to (un-)register it via the regsvr32 cmd-prompt application, as it doesn't have any DLL (Un-)registry entry points.
The TlbImp.exe cmd-prompt application can't handle it.
So basically, after discovering the above (after trying the most-common internet solutions), I still feel quite dissatisfied to get the error message while I try to solve the optimization -
Unable to load DLL 'lpsolve55.dll': The specified module could not be found. (Exception from HRESULT: 0x8007007E)
The wierd part is also that I have another project in which I solve a similar problem, where there are absolutely no problems at all using lpsolve55.dll....
Some quick facts:
I reference .NET framwork 4.5.2. I have changed it to 4.5 as well as 4.0, but this didn't change anyting.
For as far as I can tell, the bin/debug folder of my projects are identical.
I am working on a fully updated windows 10 OS, 64 bits, while using visual studio 2015.
My question would thus be whether or not some of you have encountered a similar problem and if you were able to solve it in some way.
Highly appreciated!

After some careful analysis, I have found the answer to the problem. To be honest, as most things are, it was quite simple in the end. The lpsolve55.dll wasn't recognized because I didn't have my new bin-folder in the Path, which I did have with my old project. I simply forgot.
On a further note however, after the lpsolve55.dll directory was added to the path, I still got an error telling me there was no model to be found that could solve my directive. Since the error occured when I was calling the LPSolverDirective(), some research landed me on the following page:
http://lpsolve.sourceforge.net/5.5/MSF.htm
Above page gives a complete and stable way of how to acces lpsolve55.dll using the LPSolverPlugin straight out of Microsoft.Solver.Foundation.dll. After following the method in the link that involves editing my projects' bin/Debug and bin/Release folders, I got the LP model up and running within no-time.
Morale of the story - read the documentation. I am a bit of a beginner in programming entire multi-project solutions and using customly-added dlls, but hopefully this helps someone else experiencing the same. In the end, I learned a lot by simply trying different methods of getting it to work, so no time was wasted.

Script# and compiler problems

I've just come across a pretty strange problem with VS2010 and Script#, which most of the time I am able to re-create.
In my simple scenario I have 2 projects in my solution; a standard Asp.Net MVC2 Web Application, and a Script# jQuery Class Library. I created a static class (attributed with [Imported]) with a static method on it, the intention being that I can map this class in code to an external Javascript library, as described in the documentation.
However, it seems that whenever I decorate such a class with [IgnoreNamespace] to achieve this goal, the project stops successfully compiling but doesn't give me any feedback as to why it's failing (no errors in the error window, for example). It's not easy to get rid of either, as Visual Studio seems to get into a permanent state of not build failure; removing the classes and project files doesn't solve it, nor restarting visual studio. The only way I can get VS to build the project successfully is to delete the project entirely, create a new one then add the files back in, which is annoying to say the least.
With a verbose build output setting, I get the following:
Target "AfterCompile" in file "C:\Program Files (x86)\ScriptSharp\v1.0\ScriptSharp.targets" from project "e:\project\local\ScriptSharpDemo\Scripts\Scripts.csproj" (target "Compile" depends on it):
Task "ScriptCompilerTask"
Done executing task "ScriptCompilerTask" -- FAILED.
Done building target "AfterCompile" in project "Scripts.csproj" -- FAILED.
.. which doesn't tell me whole lot.
There have been a couple of times where I have managed to create this type of class and then successfully build, but mostly I can reproduce this problem pretty reliably.
At this point I'm inclined to think that the bug lies with Script#, but would just like to have that confirmed, and to find a possible work around if there is one.

Just in case anyone is having a similar issue, I've found the cause of the problem.
When adding a class using this method, or copying in a file from another project for use within Script#, this causes a reference to System.dll to be added to the project. This (understandably) causes the project to stop compiling without error.
It would be nice to have a warning about this or for Script# to somehow detect when this situation occurs and/or create a new template for when I use 'Add class' or import a file, but it is just a convenience issue and at least now I can painlessly get my project compiling again just by removing this reference.

When trying to make my project build again, I came across the following, possible solutions:
The "Home\HomePage.cs" and "Shared\Utility.cs" must not be deleted and remain where they wre initially created
The "Home\HomePage.cs" and "Shared\Utility.cs" must be the last entries in the "*.csproj"-file. After them, no "Compile" tag should follow
Problematic calls to "Script.Literal" might cause silent fails - especially be careful when having parameters (like Script.Literal("{0}.doFoo()", variable))
The same seems to be true for "String.Format" when the format parameters are invalid
Namespaces and folders seem to cause many problems, putting all classes into the same namespace and all classes into the same folder might help

I tried all of the suggestions that have been given here, but continued to see the issue. Eventually, I determined that the cause in my situation was that I had added an [IntrinsicProperty] attribute to one of my properties. Removing it solved the issue. Don't ask me why this was causing a problem, but I thought I would share this solution in case others run into it.