compile by csc.exe without VS and .NET Framework SDK - c#

I have 2 windows machines:
Machine1 has Visual Studio 2010;
Machine2 has only .NET Framework 4.0 Client Profile without any Visual Studio or .NET Framework SDK.
Compiling one simple C# test (test.cs includes "using System.Data;"):
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\csc.exe /target:exe test.cs
It works fine on Machine1.
But failed on Machine2 with:
test.cs(2,14): error CS0234: The type or namespace name 'Data' does not exist in
the namespace 'System' (are you missing an assembly reference?)
I copied the "C:\Windows\Microsoft.NET\Framework64\v4.0.30319\System.Data.dll" to the current directory but it still failed.
Added "/r:system.data.dll" when compiling will work:
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\csc.exe /r:system.data.dll /target:exe test.cs
Do you know the reason?

The compiler will attempt to automatically load a file named csc.rsp, a file that contains default compile options. Unless you compile with the /noconfig option. That file contains a bunch of /reference options for common .NET Framework assemblies, System.Data.dll is one of them.
There is a csc.rsp file on all my machines, it is located for example in C:\Windows\Microsoft.NET\Framework\v4.0.30319 on the one I'm using now.
So very high odds that you are using a machine that doesn't have that file. I don't know if that's specific to the Client profile, I've always avoided it. But a quick check with Windows Explorer will give you a hint.

The .NET Client Profile is a cut-down version of .NET intended for client (user interface) applications. Not all of the assemblies and classes provided in the full .NET exist in the Client Profile. If you wish to write and application that works on both, you will have to restrict yourself to just those classes and assemblies that exist in the Client Profile (as it is a subset).
You may find it more convenient to simply install the full .NET on machine 2.
Notice also that, as of .NET 4.5, the Client Profile no longer exists.

Related

CryptoObfuscator error obfuscating UWP assembly

When trying to obfuscate a UWP (WinRT) AnyCPU assembly using CryptoObfuscator, the following error messages are observed:
1.) When merging in LogicNP.CryptoLicensing.WinRT.dll (a WinRT assembly) into a UWP DLL:
Error occurred while obfuscation: - .Net framework version type of the licensing assembly (Silverlight) does not match the version type of the obfuscating assembly (Normal).
2.) When merging of the licensing assembly is ignored:
Error occurred while obfuscation: System.IO.FileNotFoundException - System.IO.FileNotFoundException: could not result: System.Runtime, Version=4.0.20.0, Culture=neutral... Specify the path where this assembly resides using 'Search Directories'
Has anyone successfully used CryptoObfuscator (which is advertised as working on any .NET assembly) successfully?
There are in fact two issues to take into account when using CryptObfuscator in this scenario:
To obfuscate for other .NET versions, the following must be added to each relevant csproj in addition to setting the target framework to :
<CopyLocalLockFileAssemblies>true</CopyLocalLockFileAssemblies>
This resolves most can not find file issues when obfuscating.
For System.Runtime, you will need to download and open the NuGet package of System.Runtime. In the lib folder you will find some nice hacks that depend on the CLR in use and glue the rest of your .NET assemblies together with the CLR, such as using forwarded types for .NET 4.7. But in the ref folder such as for netstandard1.5 you will find a System.Runtime.dll. Copy that one manually to the output folder or a location where CryptoObfuscator will search.
You can also put it in another folder, and specify in CryptoObfuscator a search directory using Project Properties or in XML:
<SearchDirectories>
<SearchDirectory Path="PATH" />
</SearchDirectories>
Try Download from nuget "Microsoft.NETCore.UniversalWindowsPlatform" and copy "System.Runtime.dll" downloaded from nuget to CryptoObfuscator folder.

c# project with CI build - reference to Oracle extension causes build error

I have a C# app build in MS VisualStudio (2015) and it's checked in to a VisualStudio repository hosted for the company I work for.
I defined a 'Build' profile on the VisualStudio server with 'Continuous Integration' on, so it builds every time there's a check in.
It's been working fine until now...
I had to add some code that called an Oracle Server, so in my code I have
OracleConnection conn = new OracleConnection(connString);
...
and at the top
using Oracle.ManagedDataAccess.Client;
and in my Project I did:
Add > Reference > Assemblies > Extensions > Oracle.ManagedDataAccess
so, it all builds and runs on my development PC.
On the TeamFoundationServer however, the build fails now with message
Error CS0246: The type or namespace name 'Oracle' could not be found (are you missing a using directive or an assembly reference?)
on the using line of the source file.
I assumed that the server would include the Oracle extension because it's now referenced in the project file (which is checked in). Is there another step I need to take?
The assemblies listed in the Extensions list are ones provided by extensions you've installed into Visual Studio (my guess is you've installed the 'Oracle Developer Tools for Visual Studio' extension).
Because this extension hasn't been installed on your build server (and nor should it) the build server naturally complains that it can't find the reference.
The solution is to remove the reference you've added an instead add a reference to the NuGet package containing the Oracle driver. This looks to be the correct one: https://www.nuget.org/packages/Oracle.ManagedDataAccess/
Your build server will then fetch the NuGet package as it would for any other assembly.

The type 'Microsoft.SqlServer.Dts.Runtime.Wrapper.ApplicationClass' has no constructors defined

I recently need to do an upgrade on my project from .net 3.5 to .net 4 and connect to the new SQL server 2008 R2. After I upgrade and compile, it throws these 2 errors:
Interop type 'Microsoft.SqlServer.Dts.Runtime.Wrapper.ApplicationClass' cannot be embedded. Use the applicable interface instead.
The type 'Microsoft.SqlServer.Dts.Runtime.Wrapper.ApplicationClass' has no constructors defined
the code throw out this error is on the ApplicationClass:
IDTSApplication90 app = new ApplicationClass();
I have this dll in the bin folder: Microsoft.SqlServer.DTSRuntimeWrap.dll
This dll's version is 9.0.242.0
I think .NET 4 doesn't like it. So I ask our DBA to search this file in the server to look for version 10. She told me this file doesn't exist in the sql server.
What do I do to resolve this issue?
For 2008 R2 correct version of this dll is 10.50.1600.1 and I've got it in C:\Program Files (x86)\Microsoft SQL Server\100\SDK\Assemblies. Try searching there.
According MSDN:
The Microsoft.SqlServer.Dts.Runtime.Wrapper namespace provides the
classes and interfaces used to create Control Flow components in the
runtime. This assembly is a Primary Interop Assembly (PIA) for the
namespace Microsoft.SqlServer.Dts.Runtime, which is the assembly
Microsoft.SqlServer.ManagedDTS (in
microsoft.sqlserver.manageddts.dll). The classes in this namespace
should not be instantiated. Instead, use the classes found in the
Microsoft.SqlServer.Dts.Runtime.
I think you should rewrite your code to use classes from Microsoft.SqlServer.Dts.Runtime namespace. Application from this namespace can be instantiated - I've used it.
Example which loads and executes package you can find here.

Global assembly cache and dlls

We have a class library we ve created using C# and .NET 3.5. The highest leveled namespace in the namespace hierarchy of that class library is say Abc.
When we use the output dll of the class library (Abc.MyLibrary.dll) in a test application in another test machine, it gives a compile time error saying Abc.dll is missing.
But when we build the class library within that test machine, then it gives no error and compiles.
Is this something related to GAC or is there any other reason for this conflicting situation?
Thanks in advance
It depends on your exact project settings, but Visual Studio might install the Assembly to the Global Assembly Cache.
Use Gacutil.exe AssemblyName from the Visual Studio Command line to check if it is installed or not.

The type or namespace name could not be found [duplicate]

This question already has answers here:
Getting "type or namespace name could not be found" but everything seems ok?
(44 answers)
Closed 8 years ago.
I have a C# solution with several projects in Visual Studio 2010.
One is a test project (I'll call it "PrjTest"), the other is a Windows Forms Application project (I'll call it "PrjForm"). There is also a third project referenced by PrjForm, which it is able to reference and use successfully.
PrjForm references PrjTest, and PrjForm has a class with a using statement:
using PrjTest;
Reference has been correctly added
using statement is correctly in place
Spelling is correct
PrjTest builds successfully
PrjForm almost builds, but breaks on the using PrjTest; line with the error:
The type or namespace name 'PrjTest' could not be found (are you missing a using directive or an assembly reference?)
I've tried the following to resolve this:
Removed Resharper (since Resharper had no trouble recognizing the referenced project, I thought it might be worth a shot)
Removed and re-added the reference and using statement
Recreated PrjForm from scratch
PrjForm currently resides inside the PrjTest folder, I tried moving it to an outside folder
Loaded the solution on a different computer with a fresh copy of VS 2010
I have done my homework and spent far too long looking for an answer online, none of the solutions has helped yet.
What else could I try?
See this question.
Turns out this was a client profiling issue.
PrjForm was set to ".Net Framework 4 Client Profile"
I changed it to ".Net Framework 4", and now I have a successful build.
Thanks everyone!
I guess it figures that after all that time spent searching online, I find the solution minutes after posting, I guess the trick is knowing the right question to ask..
In my case I had:
Referenced DLL : .NET 4.5
Project : .NET 4.0
Because of the above mismatch, the 4.0 project couldn't see inside the namespace of the 4.5 .DLL. I recompiled the .DLL to target .NET 4.0 and I was fine.
PrjForm was set to ".Net Framework 4 Client Profile" I changed it to ".Net Framework 4", and now I have a successful build.
This worked for me too. Thanks a lot. I was trying an RDF example for dotNet where in I downloaded kit from dotnetrdf.
NET4 Client Profile:
Always target NET4 Client Profile for all your client desktop applications (including Windows Forms and WPF apps).
NET4 Full framework:
Target NET4 Full only if the features or assemblies that your app need are not included in the Client Profile. This includes:
If you are building Server apps, Such as:
ASP.Net apps
Server-side ASMX based web services
If you use legacy client scenarios, Such as:
o Use System.Data.OracleClient.dll which is deprecated in NET4 and not included in the Client Profile.
Use legacy Windows Workflow
Foundation 3.0 or 3.5 (WF3.0 , WF3.5)
If you targeting developer scenarios and need tool such as MSBuild or need access to design assemblies such as System.Design.dll
Another thing that can cause this error is having NuGet packages that have been built with a newer version of .NET.
The original error:
frmTestPlanSelector.cs(11,7): error CS0246: The type or namespace name 'DatabaseManager'
could not be found (are you missing a using directive or an assembly reference?)
Further up in the log I found this:
C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets(1605,5): warning MSB3275: The primary reference "[redacted]\DatabaseManager\bin\Release\DatabaseManager.dll" could not be resolved because it has an indirect dependency on the assembly "System.Data.SQLite, Version=1.0.94.0, Culture=neutral, PublicKeyToken=db937bc2d44ff139" which was built against the ".NETFramework,Version=v4.5" framework. This is a higher version than the currently targeted framework ".NETFramework,Version=v4.0".
The solution was to re-install the NuGet packages:
http://docs.nuget.org/docs/workflows/reinstalling-packages
I solved mine because the other project was coded with .NET 4.5 and the other one was coded 4.0
The using statement refers to a namespace, not a project.
Make sure that you have the appropriately named namespace in your referenced project:
namespace PrjTest
{
public class Foo
{
// etc...
}
}
Read more about namespaces on MSDN:
Using Namespaces
I encountered this issue it turned out to be.
Project B references Project A.
Project A compiled as A.dll (assembly name = A).
Project B compiled as A.dll (assembly name A).
Visual Studio 2010 wasn't catching this. Resharper was okay, but wouldn't compile. WinForms designer gave misleading error message saying likely resulting from incompatbile platform targets.
The solution, after a painful day, was to make sure assemblies don't have same name.
It is also possible, that the referenced projects targets .NET 4.0, while the Console App Project targets .NET 4.0 Client Library.
While it might not have been related to this particular case, I think someone else can find this information useful.
The compiled dll should have public Class.
I had the same issue. The target frameworks were fine for me. Still it was not working.
I installed VS2010 sp1, and did a "Rebuild" on the PrjTest. Then it started working for me.
Other problem that might be causing such behavior are build configurations.
I had two projects with configurations set to be built to specific folders.
Like Debug and Any CPU and in second it was Debug and x86.
What I did I went to Solution->Context menu->Properties->Configuration properties->Configuration and I set all my projects to use same configurations Debug and x86 and also checked Build tick mark.
Then projects started to build correctly and were able to see namespaces.
Changing the framework to
.NET Framework 4 Client Profile
did the job for me.
For COM/ActiveX references, VS 2012 will show this error right on using statement. Which is quite funny, since it's saying that may be you are missing a using statement.
To solve this: register the actual COM/ActiveX dll even if it's in the neighbor project, and add a reference through COM channel, not project channel. It will add Interop.ProjectName instead of ProjectName as a reference and this solves this strange bug.
If your project (PrjTest) does not expose any public types within the PrjTest namespace, it will cause that error.
Does the project (PrjTest) include any classes or types in the "PrjTest" namespace which are public?
just changed Application's target framework to ".Net Framework 4".
And error got Disappeared.
good luck;
:D
check your Project Properties, your Reference Paths should be empty like this:
Regards

Categories

Resources